Chronos
Member
Sounds like you are activating Segregated Brain for this implementation, as well.
Segregated Witness Sotf fork (Segwit) Pros and Cons
- Thread starter adamstgbit
- Start date
- Mar 13, 2016
- 1,206
- 2,650
after doing both 2MB pros and cons and Segwit pros and cons, its clear as day, if your looking to improve bitcoin scaling segwit is NOT ideal or in anyway better, the #1 reason i hear that segwit is better is due to sotffork Vs HardFork.
considering all the red text below the pro "segwit is a softfork".... that is a BS reason.
Futher more, I dont believe it is safe to forget about witness data, by all means to not use it to cal TX_ID, but there is no reason to not include these in blocks other then to PRETEND segwit has a scaling effect.
devs seem fine writing bad code simply so they can communicate half truths to the community and get there way.
"we realized if we did segwit a certain way we'll get a scaling effect" <- drity code for a convincing argument
"we realized segwit could be done as a sotffork" <- dirty code for a convincing argument
i am not happy...
considering all the red text below the pro "segwit is a softfork".... that is a BS reason.
Futher more, I dont believe it is safe to forget about witness data, by all means to not use it to cal TX_ID, but there is no reason to not include these in blocks other then to PRETEND segwit has a scaling effect.
devs seem fine writing bad code simply so they can communicate half truths to the community and get there way.
"we realized if we did segwit a certain way we'll get a scaling effect" <- drity code for a convincing argument
"we realized segwit could be done as a sotffork" <- dirty code for a convincing argument
i am not happy...
there is no need to include the wtxid in the witness data, the normal txid are not included in current blocks either, so this is not any change.
Basically there is a blob of data, you hash it and get the (w)txid
so as long as you have the blob of data that matches, it is good
while if any bit is messed up, you wont be able to figure out which bit it is, at least it detects that the entire set of data has something wrong with it
https://en.wikipedia.org/wiki/Merkle_tree
so if they included the wtxid in the witness data, it would be less efficient than now. It is actually quite clever method to get it to not be significantly larger. Compared to the overall size 2 bytes per tx and 1 byte per vin is small, so it wouldnt be fair to say segwit bloats things due to ~1% extra
But of course to say that segwit makes things smaller, this is even a worse position.
I finally figured out why they are claiming it is 30% smaller. The segwit allows them at some point in the future to change the signature method that could be 30% smaller. But to do a bifurcating softfork before this 30% optimized signature method is ready, that seems very strange indeed.
Since increasing blocksize via 2MB hardfork is 1000x (yes that is not a typo) simpler to do, if segwit softfork is meant to just buy time, it would be much, much safer to do the 2MB HF first.
segwit has cool tech, it allows many new usecases, it just shouldnt be stealth released onto mainnet under the guise of scalability. The problems with segwit are not its tech, but the marketing, the process abuse and other aspects.
I had to make a big point yesterday and took some arrows over it, but the net result is that three of the core devs publicly admitted that segwit does not save any permanent space.
The big question is why the big rush for segwit before it is ready?
Basically there is a blob of data, you hash it and get the (w)txid
so as long as you have the blob of data that matches, it is good
while if any bit is messed up, you wont be able to figure out which bit it is, at least it detects that the entire set of data has something wrong with it
https://en.wikipedia.org/wiki/Merkle_tree
so if they included the wtxid in the witness data, it would be less efficient than now. It is actually quite clever method to get it to not be significantly larger. Compared to the overall size 2 bytes per tx and 1 byte per vin is small, so it wouldnt be fair to say segwit bloats things due to ~1% extra
But of course to say that segwit makes things smaller, this is even a worse position.
I finally figured out why they are claiming it is 30% smaller. The segwit allows them at some point in the future to change the signature method that could be 30% smaller. But to do a bifurcating softfork before this 30% optimized signature method is ready, that seems very strange indeed.
Since increasing blocksize via 2MB hardfork is 1000x (yes that is not a typo) simpler to do, if segwit softfork is meant to just buy time, it would be much, much safer to do the 2MB HF first.
segwit has cool tech, it allows many new usecases, it just shouldnt be stealth released onto mainnet under the guise of scalability. The problems with segwit are not its tech, but the marketing, the process abuse and other aspects.
I had to make a big point yesterday and took some arrows over it, but the net result is that three of the core devs publicly admitted that segwit does not save any permanent space.
The big question is why the big rush for segwit before it is ready?
- Mar 13, 2016
- 1,206
- 2,650
why the rush?
because blocks are full and its hurting adoption and putting fee pressure, we'll be at 10cent / TX very soon.
of course 2MB is the better solution to that problem...
but the core devs dont actually see this as a problem, infact they are counting on this problem to make LN and sidechain project more profitable.
the way they see it is segwit will effectively increase capacity ( thats true, even if is not more efficient than simply increasing block size) and then there's no more problem, bitcoin doesn't need to scale any further, the second layer will carry it the rest of the way
why do you think they gave themselfs a full year to review +2MB blocklimit, because they figure by that time they will have the second layer running, and they can simply say, we dont need 2MB we have the second layer ready.
[doublepost=1458241762][/doublepost]if it was up to core devs segwit would not effectively increase capacity, and they would have fee pressure build up till LN come alone, peter todd said this himself in an interview! coding segwit in such a way as to increase capacity, is a compromise.
thats what the HK round table was about, miner said " give us more capacity on the main chain or we go to classic "
devs were like GRRRRRR fine....
because blocks are full and its hurting adoption and putting fee pressure, we'll be at 10cent / TX very soon.
of course 2MB is the better solution to that problem...
but the core devs dont actually see this as a problem, infact they are counting on this problem to make LN and sidechain project more profitable.
the way they see it is segwit will effectively increase capacity ( thats true, even if is not more efficient than simply increasing block size) and then there's no more problem, bitcoin doesn't need to scale any further, the second layer will carry it the rest of the way
why do you think they gave themselfs a full year to review +2MB blocklimit, because they figure by that time they will have the second layer running, and they can simply say, we dont need 2MB we have the second layer ready.
[doublepost=1458241762][/doublepost]if it was up to core devs segwit would not effectively increase capacity, and they would have fee pressure build up till LN come alone, peter todd said this himself in an interview! coding segwit in such a way as to increase capacity, is a compromise.
thats what the HK round table was about, miner said " give us more capacity on the main chain or we go to classic "
devs were like GRRRRRR fine....
so basically nothing to do with tech, just using the leverage to give advantage to a company?
when I am being told to not bother with iguana, since it is impossible to do a bitcoin core and then whenever I post, it seems I am called names, or told my code is bad, my design is bad, it is only hypothetical, etc.
then when I ask questions about how segwit saves space when it uses more space, I get a massive lecture about not understanding bitcoin, etc. Like they want to discourage me from learning about the bitcoin and certainly dont want any alternate core.
When there is long rant that ends with "Shame on you, and shame on you for having no shame." end of https://bitcointalk.org/index.php?topic=1398994.msg14222399#msg14222399
if I didnt see a good chance for classic to become the defacto bitcoin core, I would seriously consider moving to a different coin. I think if we made a tech roadmap that makes both miners and users happy and give people a real choice with better tech, then why would people continue working for such an abusive tyrant?
[doublepost=1458243568][/doublepost]your post about merkle trees reminded me I still had to add merkle_root verification. They make it out to be some mysterious complicated thing, but really it is just a few lines of code that took literally less than an hour to code and debug:
The above makes the entire merkle tree in place, without any pointers and is reasonably efficient. Of course the endian is flipped for historical reasons, when my 2 tx merkle was wrong, i figured it has to be the endian isssu
when I am being told to not bother with iguana, since it is impossible to do a bitcoin core and then whenever I post, it seems I am called names, or told my code is bad, my design is bad, it is only hypothetical, etc.
then when I ask questions about how segwit saves space when it uses more space, I get a massive lecture about not understanding bitcoin, etc. Like they want to discourage me from learning about the bitcoin and certainly dont want any alternate core.
When there is long rant that ends with "Shame on you, and shame on you for having no shame." end of https://bitcointalk.org/index.php?topic=1398994.msg14222399#msg14222399
if I didnt see a good chance for classic to become the defacto bitcoin core, I would seriously consider moving to a different coin. I think if we made a tech roadmap that makes both miners and users happy and give people a real choice with better tech, then why would people continue working for such an abusive tyrant?
[doublepost=1458243568][/doublepost]your post about merkle trees reminded me I still had to add merkle_root verification. They make it out to be some mysterious complicated thing, but really it is just a few lines of code that took literally less than an hour to code and debug:
Code:
bits256 iguana_merkle(struct iguana_info *coin,bits256 *tree,struct iguana_msgtx *txarray,int32_t txn_count)
{
int32_t i,n=0,prev; uint8_t serialized[sizeof(bits256) * 2];
if ( txn_count == 1 )
return(txarray[0].txid);
for (i=0; i<txn_count; i++)
tree[i] = txarray[i].txid;
prev = 0;
while ( txn_count > 1 )
{
if ( (txn_count & 1) != 0 )
tree[prev + txn_count] = tree[prev + txn_count-1], txn_count++;
n += txn_count;
for (i=0; i<txn_count; i+=2)
{
iguana_rwbignum(1,serialized,sizeof(*tree),tree[prev + i].bytes);
iguana_rwbignum(1,&serialized[sizeof(*tree)],sizeof(*tree),tree[prev + i + 1].bytes);
tree[n + (i >> 1)] = bits256_doublesha256(0,serialized,sizeof(serialized));
}
prev = n;
txn_count >>= 1;
}
return(tree[n]);
}- Mar 13, 2016
- 1,206
- 2,650
side note: I can't believe bitcoin somehow inherited the little/big endian problem. it would be interesting to know why its comes into play.
I should have taken the job as jr. core dev back in 2012...
I should have taken the job as jr. core dev back in 2012...
This is simply not true. At the very worst users will end up with funds that they cannot verfiy, until they try to spend them. This may open up attack vectors against them, but they will not lose bitcoin that they have by spending them, as they would in a hard fork. All soft forks end up being mandatory for miners once 95% adoption is reached. All soft fork's end up with degraded capabilities for non-upgraded nodes. That's what a soft fork is!
Seriously you can argue against "soft fork segregrated witness" in a number of ways, but you cannot say it is not a soft fork.
- Mar 13, 2016
- 1,206
- 2,650
@Lee Adams
thanks for your input
would it be fair to say:
wallets that do not upgrade and receive funds from a segwit TX will end up with funds which they cannot verify. older nodes could be fooled by invalid segwit-TXs with no way of verifying these funds other than to try and spend them.
sure its a softfork technically, but pretty soon after some % of nodes start doing segwit TX, your older wallet is compatible but quite handicapped.
its not like they simply do not get a new feather...
ex pruning, old node simply can't prun their blockchain, its not like this impairs their functionally or anything. they dont NEED the new feather they can CHOOSE to not upgrade and will remain 100% functional
i guess somthing like Xthin blocks is another example?
segwit is a pretty bad ass softfork...
thanks for your input
would it be fair to say:
wallets that do not upgrade and receive funds from a segwit TX will end up with funds which they cannot verify. older nodes could be fooled by invalid segwit-TXs with no way of verifying these funds other than to try and spend them.
sure its a softfork technically, but pretty soon after some % of nodes start doing segwit TX, your older wallet is compatible but quite handicapped.
its not like they simply do not get a new feather...
ex pruning, old node simply can't prun their blockchain, its not like this impairs their functionally or anything. they dont NEED the new feather they can CHOOSE to not upgrade and will remain 100% functional
i guess somthing like Xthin blocks is another example?
segwit is a pretty bad ass softfork...
Last edited:
This is the bit that is not correct as far as I can see. Old wallets will not be able to receive seg wit transactions. However they may be able to receive coins which were seg wit transacted in the past. That is the case where the old wallet may not be able to verify the coins. Again as this is pretty unclear at the moment, it would be great if this was included in an FAQ somewhere.
This pretty much describes any soft fork. See https://blog.blockchain.com/2016/02/26/a-brief-history-of-bitcoin-forks/
- Mar 13, 2016
- 1,206
- 2,650
the definition of softfork is way to relaxed...
a softfork should be a change in the code which has 0 impact on an older node talking to a newnode.
example: a change in the way a client validates a block in a more optimized way. this wouldn't impact anything as far as old node Vs new nodes compatibility.
segwit pushes the definition of softfork to its limits...
it is unfair to say non-segwit node will have no compatibility issues with segwit node
old nodes will be "confused" by the new nodes segwit TX, they will be able to handle them as anyone-can-spend TXs, this is a misinterpretation...
its not black and white, some changes have more impact than others... segwit BARELY qualifies as a softfork, and its impl. has to be done in an inefficient manner to allow its backward compatibility.
[doublepost=1458320200][/doublepost]they should define a list of forks names to better communicate how the fork impacts backward compatibility
minor-fork = tiny change that effects nothing really
sotf-fork = 0 impact on backward compatibility,
major-fork = old nodes to misinterpret things, but otherwise continue functioning
hard-fork = old node are no longer compatible
a softfork should be a change in the code which has 0 impact on an older node talking to a newnode.
example: a change in the way a client validates a block in a more optimized way. this wouldn't impact anything as far as old node Vs new nodes compatibility.
segwit pushes the definition of softfork to its limits...
it is unfair to say non-segwit node will have no compatibility issues with segwit node
old nodes will be "confused" by the new nodes segwit TX, they will be able to handle them as anyone-can-spend TXs, this is a misinterpretation...
its not black and white, some changes have more impact than others... segwit BARELY qualifies as a softfork, and its impl. has to be done in an inefficient manner to allow its backward compatibility.
[doublepost=1458320200][/doublepost]they should define a list of forks names to better communicate how the fork impacts backward compatibility
minor-fork = tiny change that effects nothing really
sotf-fork = 0 impact on backward compatibility,
major-fork = old nodes to misinterpret things, but otherwise continue functioning
hard-fork = old node are no longer compatible
Last edited:
- Mar 13, 2016
- 1,206
- 2,650
a few edits to OP and its looking good
this captures the debating surrounding segwit, and i think any misconceptions have been corrected.
this captures the debating surrounding segwit, and i think any misconceptions have been corrected.
That's some good reasoning, but ... are you really sure?
Let's imagine a very old block 300000, it does not need witness data, and signatures can be pruned
If signature data is removed, there is no way to calculate the TXID for each transaction, then there is no way to calculate the merkle root for the block, and you can not validate the block independently. In one word, without signature data, you can not verify anything in this block is valid. Of course, you can still verify the block header, but not anything in that block, means you can just change any transaction in that block while still keep the block header valid, since now the merkle root hashed into the block header can not be reconstructed without signature data
So it seems the full nodes still have to keep all the signature data. And if a light node pruned the signature data, they won't be able to verify if an old transaction in that block is valid. If two light nodes have different transactions in the same block, which one is true? No one can tell. So they have to rely on full nodes to be functional, and what if several fake full nodes are around the corner?
There could be other attack vectors I have not thought of
And then there is another problem with segwit itself
Bitcoin nodes would not be able to verify the segwit transation because they do not receive witness data, so a segwit transaction with invalid signature data will be regarded as valid and added to a bitcoin block and extended on bitcoin chain. Of course this block will be regarded as invalid by segwit nodes, if the segwit mining nodes have majority of hash power, they can add several segwit blocks and orphan this block by extending their segwit chain, since bitcoin nodes consider segwit blocks as valid. But if some miners are doing SPV mining, they might be able to extend the bitcoin blockchain faster than segwit chain (see july 4 2015 fork), thus make the chain fork much longer
Personally, no, I'm not really clever enough to go into it in that depth. So yes I'm relying on clever people like, Gavin, GMax and even Luke-jr to assure me it is safe. They have even said that signatures are not checked before a certain block checkpoint.
Sorry what type of miner would put an invalid segwit block on the chain? I assume you mean after 75% of mining hash power has upgraded, but before 95% where this is a known issue.
Just spend some time google the transaction/block structure of bitcoin, it won't take you more than a day, bitcoin is not rocket science. I never trust any of the devs unless that is something I can understand. Mike said, "It is complex, (but) all the information an investor might want was out there, and there’s an entire cottage industry of books, conferences, videos and websites to help people make sense of it all."
If trust and hope has become people's decision making model, then bitcoin has failed. And because of this, I don't think further complicating the bitcoin architecture is the right direction
- Mar 13, 2016
- 1,206
- 2,650
There is another way to adopt a system if you are lazy: Let others run it for years and prove it is worth trusting. That's how all those complex technologies were adopted. Then in this case, segwit must be tested by other people for 7 years to reach the same acceptance level as bitcoin today, since it is a totally different architecture, another cryptocurrency
- Mar 13, 2016
- 1,206
- 2,650
I think i need to add the con
"Increased resource usage (capacity, bandwidth, processing power)"
It's not like the smoke and mirrors they use to effectively increase blocksize, will somehow increase block size without increasing requirements, much the same way 2MB blockincress would increase these requirements as well
"Increased resource usage (capacity, bandwidth, processing power)"
It's not like the smoke and mirrors they use to effectively increase blocksize, will somehow increase block size without increasing requirements, much the same way 2MB blockincress would increase these requirements as well
- Dec 16, 2015
- 2,806
- 6,088
The SegWit soft-fork, as currently planned (*) with a 75% and 95% threshold, does not comply with BIP9 - which is the accepted procedure to implement such soft forks.
https://bitco.in/forum/threads/segregated-witness.242/#post-16714
To put it plainly, that would go against Core's own accepted procedure.
(*) If Core developer James Hilliard's characterisation on Classic Slack today is accurate:
https://bitco.in/forum/threads/segregated-witness.242/#post-16714
To put it plainly, that would go against Core's own accepted procedure.
(*) If Core developer James Hilliard's characterisation on Classic Slack today is accurate:
https://bitcoinclassic.slack.com/archives/debate/p1459409472002780
Last edited:
