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

Am I wrong to assume that the large mining pool owners aren't well versed in the rudimentary basics of bitcoin? If I can understand it, I am sure they can.

Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review

We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides

ETA update-

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011875.html

"- Segwit BIP is being written, but has not yet been published.

  - Gregory linked to an implementation but as he mentions it is not completely
    finished yet. ETA for a Segwit testnet* is later this month, then you can test as well.

Wladimir"


I assume Wladimir is refering to rolling segwit into the main bitcoin testnet instead of being tested merely in elements sidechain testnet .

More projections out of thin air. Crazy.

Ah, the ignoring user changed the title of his thread.

 It is almost as if he believes that the only thing holding bitcoin back is capacity...and as soon as we build the 100k seat stadium it will be filled. Even if these optimistic delusions are correct it would be disastrous for the bitcoin ecosystem to have that rapid of growth in such short order.

I am so glad there are enough rational and calm developers contributing and who are aware of the nuances and trade offs in decentralization and security.


Define simple. Bitpays BiP 101 patch actually has more lines of code than the SW softfork.

Some say that a 'monster softfork' would be a dumber 'immediate' short term last minute solution than a simple increase of the block size, when everyone can see that the capacity is at the limit right now and the halving event is just 7 month away.

If this is your impression of being welcoming, then I'd certainly avoid any event where you were greeting the guests.

And more doomsday deadline scaremongering, after last time? Come on now.

No developer is suggesting it is "the solution". The fact that you cannot see that after we keep clarifying and providing contrary evidence suggests you are acting irrationally.


Serious people do not pretend to know the how quickly we will need to scale the capacity needs in the future.

This is why a very responsible approach is outlined here-




If we make sloppy and dumb capacity upgrades in fear and haste we don't have the right incentives to make the right tradeoffs and develop optimal solutions which benefit all. There is no harm in having tested backup plans if the need arises and demand increases more than expected.

The paypal and Visa network have outages all the time and the ecosystem doesn't simply crumble in chaos. with bitcoin the worst fear is some transactions being delayed from confirmation while payment processors rely on 0 conf verification more heavily while an agreed upon and tested hardfork gets deployed. This is far less of an issue than the Visa payment network/paypal being down.   

"I think that right
now capacity is high enough and the needed capacity is low enough that
we don't immediately need these proposals, but they will be critically
important long term."

Is this a joke? What is long term? 1 month before the halving date oder 1 month after?

Your stupid projections. Are you crazy? We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.

It was never presented or intended to be "the solution" and merely a small peice of a puzzle in a comprehensive and holistic approach to addressing Scalability and capacity.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Just ignore anyone who ignores this:
There already was an airplane analogy. Re-read the whole thread.

I've updated the thread title a bit.

I don't understand any of this, maybe there can be something written for the less technical among us?

Lol you clearly still cant read with any proficiency.


You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.

All in all, seems to be even less than a x2 capacity increase:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

For how many month will it be 'the solution' in 2016, the year of the Great Halvening? April or even May?

https://www.reddit.com/r/Bitcoin/comments/3vurqp/greg_maxwell_capacity_increases_for_the_bitcoin/


Here is an exact breakdown of an example of the savings in overhead and why capacity can increase-

What are you talking about? Advantages: 4x increase in traffic that is possible via a soft fork, fix to malleability, simpler script upgrades (quite important as well), fraud proof, less bandwidth for light nodes and historical sync. I think that it could help full nodes (not sure yet) by not syncing all of the historical data (i.e. signatures), because it isn't really needed. More discussion about this is definitely needed.

"What are the advantages of this? It allows you to drop the signatures from relay whenever you are relaying to a node that is not actually doing full-validation at the time. "

So this solution still does not help full-validation nodes, it only improve the relay speed for SPV nodes. But SPV nodes could just connect to the latest full node to get faster access, they are not the bottleneck for the whole network

I have watched this video twice but still don't really get it

So far as I understand Pieter's proposal, a spending transaction is first validated by the mining nodes by checking its signature, then after it is validated, the node will include the transaction in the next mined block, but without that signature

However, this will create a security question for the other nodes receiving such a block: Without signature, how do they know the transaction is valid? Is it possible for a rougue node to forge a block with lots of invalid transctions but appears to be all validated by that node?

Normally all the adjacent nodes have similar mempool which contains similar transactions. If a transaction is already in their mempool they will know it is valid or not. However, if a new block arrives from far apart which contains many transactions not in their mempool, they need all the data of the transaction, especially the signature to validate it

Otherwise you would be able to spend bitcoin at any address without the signature

I'm not very sure how it works today, e.g. what kind of check other nodes do to make sure it is a valid block with all valid transactions, have to check it back


A side thought: I suppose the original Satoshi client design tried his best to be both secure and efficient. If there is such a large room of efficient increase without impacting security, why it has not been implemented before?

I remember 2-3 years ago there was a talk about the separation of transaction data using two chains to get rid of the forever growing block size pain, then after some deeper discussion it turns out you can not secure the separated part from being tampered, so it seems everything in a transaction is a whole and need to be included and secured by hash power altogether, which is the most efficient way