Topic: Segregated witness - The solution to Scalability (short term)? - page 14. (Read 23170 times)

I like that it seems we are making slow but steady progress in reaching a consensus, my question is why is gavin advocating for a hard fork to do this when soft fork should be enough?

I like that it seems we are making slow but steady progress in reaching a consensus, my question is why is gavin advocating for a hard fork to do this when soft fork should be enough?

Thanks for laying out a road-map, Greg.

I'll need to think about it some more, but just a couple of initial
reactions:

Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
coinbase is messy and will just complicate consensus-critical code (as
opposed to making the right side of the merkle tree in block.version=5
blocks the segwitness data).

It will also make any segwitness fraud proofs significantly larger (merkle
path versus merkle path to coinbase transactions, plus ENTIRE coinbase
transaction, which might be quite large, plus merkle path up to root).


We also need to fix the O(n^2) sighash problem as an additional BIP for ANY
blocksize increase. That also argues for a hard fork-- it is much easier to
fix it correctly and simplify the consensus code than to continue to apply
band-aid fixes on top of something fundamentally broken.


Segwitness will require a hard or soft-fork rollout, then a significant
fraction of the transaction-producing wallets to upgrade and start
supporting segwitness-style transactions. I think it will be much quicker
than the P2SH rollout, because the biggest transaction producers have a
strong motivation to lower their fees, and it won't require a new type of
bitcoin address to fund wallets. But it still feels like it'll be six
months to a year at the earliest before any relief from the current
problems we're seeing from blocks filling up.

Segwitness will make the current bottleneck (block propagation) a little
worse in the short term, because of the extra fraud-proof data. Benefits
well worth the costs.

------------------

I think a barrier to quickly getting consensus might be a fundamental
difference of opinion on this:
"Even without them I believe we’ll be in an acceptable position with
respect to capacity in the near term"

The heaviest users of the Bitcoin network (businesses who generate tens of
thousands of transactions per day on behalf of their customers) would
strongly disgree; the current state of affairs is NOT acceptable to them.
--
--
Gavin Andresen

Gavin Andresen has posted a pretty good explanation that is not overly technical:

http://gavinandresen.ninja/segregated-witness-is-cool

As merely one question, can we really consider the signature as something that's not needed?

I get that we're not _eliminating_ the sig, merely putting it in a separate (segregated) container, apart from the rest of the transaction. But any entity that wants to operate bitcoin in a trustless manner is going to need to be able to fully validate each transaction. Such entities will need the signature, right? Accordingly, such entities will need both components, so no data reduction for them, right?

Currently, relay nodes verify each transaction before forwarding it, do they not? If they are denied the signature, they can no longer perform this verification. This seems to me to be a drastically altered division of responsibilities. Sure, this may still work, but how do we know whether this is a good repartitioning of the problem?

Further, does this open a new attack vector? If 'nodes' are going to stop validating transactions before forwarding them, then there is nothing to stop them from forwarding invalid transactions. What if an attacker were to inject many invalid transactions into the network? Being invalid, they would be essentially free to create in virtually unbounded quantities. If nodes are no longer validating before forwarding, this would result in 'invalid transaction storms', which could consume many times the bandwidth of the relatively small number of actual valid traffic. If indeed this is a valid concern, then this would work exactly contrary to its stated goal of increasing scalability.

Note I am not making any claims here, but I am asking questions, prompted from my incomplete understanding of this feature.

Which is fine. I get that. But 'I really don't quite understand yet how this is going to work, exactly' is kind of hard to square with 'The solution to Scalability'. If one does not understand all the considerations, how is one able to meaningfully advocate it as any kind of solution?

-snip-

Further, does this open a new attack vector? If 'nodes' are going to stop validating transactions before forwarding them, then there is nothing to stop them from forwarding invalid transactions. What if an attacker were to inject many invalid transactions into the network? Being invalid, they would be essentially free to create in virtually unbounded quantities. If nodes are no longer validating before forwarding, this would result in 'invalid transaction storms', which could consume many times the bandwidth of the relatively small number of actual valid traffic. If indeed this is a valid concern, then this would work exactly contrary to its stated goal of increasing scalability.

It sorts like a way to efficiently compress  the weight of blocks by removing something that's not needed when possible.

Like anything else in life, if it's difficult to figure out at first, then continuous exposure to the logic of the inner workings will eventually bridge the gap. That's how I learned about Bitcoin; not over 2 days worth of reading/thinking, but over 4 years. I'm still going.

Like anything else in life, if it's difficult to figure out at first, then continuous exposure to the logic of the inner workings will eventually bridge the gap. That's how I learned about Bitcoin; not over 2 days worth of reading/thinking, but over 4 years. I'm still going.

'I really don't quite understand yet how this is going to work, exactly' is kind of hard to square with 'The solution to Scalability'. If one does not understand all the considerations, how is one able to meaningfully advocate it as any kind of solution?

Maybe because we've encountered segwit only 2 days ago? Maybe it is because Bitcoin is a learning process and these things take more time as people have their personal lives to attend to? I've already said in the thread that I'm also learning on the go. There's nothing wrong with not knowing the answer to a bit more complex questions.

At the moment everything goes in the block.

With segwit, only the important stuff goes in the block. The other stuff goes into an 'attachment'.

This way more transactions can be put into a full block without increasing the blocksize limit.

And to me as if I'm just born

My worry here is that we seem to have a large cadre of proponents of this new feature that are not able to articulate answers to reasonable questions. I see a lot of demurring of the nature of "perhaps the devs can come by and explain it better". It makes be think that perhaps these proponents likewise don't understand the details of what is being proposed deeply enough to understand the implications upon the questions being asked.

Do you mean that a trustless system which depends on users trust in the "brainpool"... isn't really a trustless system anymore? But isn't this already the case?

Ok, so the fully verifying nodes are not going to benefit from the new design, then how does this design improve the communication speed between fully verifying nodes (which is the bottleneck of the current design) ?

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters