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

I see the commits from Pieter Wuille (sipa) for Segregated Witness at https://github.com/sipa/bitcoin/commits/segwit

Appears that this is a done deal, am I correct in that statement? If so when will the soft fork take place. Thanks.

I see. Thanks for responding. I have deleted my post since I am in the process of reading more about it. I didn't want to clog up the thread too much.

I must say that this is a very interesting concept. This also gives us time, if implemented, to find another long-term solution since I doubt that even a 4 times increase will be enough in the future!

Well there has been 6 months of testing and Pieter Wuille did suggest we ASAP implement this improvement so I would expect a few weeks to allow outside criticsm to be taken into account but it is going to happen quickly as his statement from the transcript is -

"This is my proposal that we do right now. We implement segregated witness right now, soon. "

Close, its actually more complicated than this because of multisig and is essentially reflecting miners having an effective increase between 1.75MB limit but less than 4 MB limit . Thus if blocks are 100% full expect ~3MB of bloat per 10 min avg for full nodes.



Many user benefits but to address your point concerning miners and full nodes:

Negatives vs status quo-
Increased Disk bloat and bandwidth requirements (Just like rasing the rate to 1.75- 3.5MB limit)

Nuetral-
UTXO unaffected

Positives-
Increased TPS capacity thus more mining fees and Better job security as profits are now diversifies from tx volume instead of reward alone which will be quickly dropping

There are other positives to miners from benefiting the overall health of the bitcoin ecosystem but I think you are trying to focus on the short term selfish incentives of miners alone absent from external motivations.



I think franky is just trying to focus on the incentive structure for miners to see how well this will work. It is a fair question to make and try and remove any external goodwill of miners and consider worst possible outcomes. Sometimes some skepticism is healthy and we shouldn't rely on the goodwill of miners to secure us into the future.... that is merely another layer of security that involves humans I appreciate.

Yeah, I can understand that. Those of us that primarily use SPV clients will still be secure. Miners will hash reduced size blocks and full nodes will be the only ones burdened with an even larger carrying capacity. Works for me. I only use lite clients now and haven't run a full node in over a year.

You know, I'm quite disappointed. Have you even looked at the picture shown in the original post? Of course you have not, else you would not be asking the ignorant question of why this is something special. All the side-effects of this are presented on that picture and they are just pure pros. Unintentional transaction malleability gets fixed, script upgrades become simpler, fraud proofs, etc.

if you increased the tx data to 4mb but kept signature to 1mb... thats just the same as having a 5mb block.. and full nodes will still have to mine upto 5mb of data whether its split or together..

so witness is not itself causing more tx per sec.. it is however usingits ninja skills to just up the block limit to 5mb under the subterfuge that its something special.

so without meandering..
explain the benefits to miners and bitcoin full node users who (imagine last week) agreed to a simple 5mb block limit increase.. and today you are trying to sell them the idea of witness..
forget about lite user benefits.. explain the benefits to the miners/full node network

well its not a side chain in itself.. but yea if you have 20 blockchains linked together.. some lite clients may want a reduced history of all chains.
although the full nodes/miners still have to deal with 20 full blockchains. lite clients can have a basic summerised copy.

i think the solution to lite clients. is to not send out a command to the network with a block height attached asking for all new blocks since X.. (to resync)
but instead send out a command to the network with a public key attached asking for all tx data of that key.

that way liteclients only store the data relevant to the keys it holds

This is all 100% true in itself as Segregating the signature isn't intended to increase TPS by itself, but with a soft fork core can increase the witness data set limit to 4MB thus indirectly increasing TPS to 6 to 28 tps. It isn't the Segregation in itself that increases the TPS but the partial and limited blocksize growth that only applies to part of the data set. Thus after the softfork there will be a 1 and 4MB limit concurrently depending upon which dataset.

Full nodes will take on more data, but lite nodes will have new features like fraud proofing (although this isn't as thorough as using a full node) and take on as much data as the blocksize limit never increased and have 6 to 28 tps.

There will than be 3 categories of nodes-
1) Traditional and the least secure SPV nodes
2) Lite / Prune nodes with SW nodes that have some fraud proofs
3) Full nodes

Well it was tested as a sidechain in elements alpha , but this is actually intended to be an immediate soft fork on the main chain.

It's not?

Ok, that doesn't seem so bad at all. It's just a sidechain solution.

1. no, its not about tx per second. its about relaying speeds of solved blocks to clients imagine it this way.
a pizza is 1mb and oneside has pepperoni, the other has anchovies.. the proposal is to cut the pizza in half but you as a full and hard worker(full node miner) still eat the same 1mb whole pizza.. thats right the full 1mb limit nothing has changed.

but because its in 2 halves, its now easier for your witness to CLONE(relay) just the pepperoni half of the pizza because he doesnt like anchovies(signatures). and thus he as a separate thing holds onto just 500kb pepperoni of his copy of the pizza

so each 10 minutes you(full node/miner) are still eating a whole 1mb pizza and your witness has cloned a copy of the pepperoni side meaning he is only eating 500kb per blocktime.

for the full nodes mining the real bitcoin blockchain. nothing has changed, the data totals are the same and thus no extra transactions can fit into bitcoins blocks. the only difference is that the miners data has a split in the middle to make it easier to relay a copy of a half to the network of lite clients..

its not changing the transactions per second. and is only reducing the data per block for the witness(liteclients) who dont want to download everything.

2.
witness wont scale anything.. its just a tool for SPV wallets to not be as bloated.. nothing to do with the real blockchain that gets mined properly
LN has more potential to scale however i have seen a few limitations that dont make it perfect.

Sounds alright to me so far, but I will need to familiarise myself better with it even still.



The presentation directly after Pieter Wuille's is a good watch. Demonstrates the (exemplary) capacity of:

• Basic Lightning (CLTV only)
• Intermediate Lightning (CLTV + CSV)
• Advanced Lightning (CLTV + CSV + Segregrated Witness)

Looks like the kind of transaction rate scaling we're after (100's of millions of users supported under the Advanced scheme)

"Size = 4*BaseSize + WitnessSize <= 4MB. For normal transaction load, it means 1.75 MB, but more for multisig."

More than 1.75 but less than 4 effective. Thus between 6 to 28 tps vs current 3-7tps.



It isn't meant to compete but merely be one piece of the puzzle that solves many other concerns as well. Sipa is positive towards other BIPs and LN. This softfork is not meant to replace a future hardfork to address scalability.


All of the core devs are familiar as this has been discussed since 2011. The only real objection is from the fact that previous to luke-jrs brilliant discovery they assumed a hard fork would be needed which would be very difficult to accomplish. I know of no core devs against this implementation because if you understand it, it is a no -brainer.

Bitcoin can and will surpass VISA alot. just be patient and wait some years my friend.

Whew, now that was a good explanation

But what amount of transaction per second would this deliver? can this really compete against LN in terms of being able to be at the same level of VISA and the like? This looks good on the surface but I would wait for someone like gmaxwell to comment on it to see potential flaws. Did any of the core devs speak on this?

An Airline only allows you to bring a limited amount of weight and bags onboard a plane for your luggage. They have to be fair and have a consistent policy for their passengers while at the same time recognize real life physical limitations and risks. There is a careful balance to be made where they make their clients happy with allowing them more luggage but at the same time keep the weight considerations reasonable for speed , limiting fuel costs and safety.

They previously had a policy of allowing 2 carry on bags weighing 10 Kg in total, but overtime with a growing economy their clients grew more wealthy and needed to travel with more bags because they were flying to Aruba for 2 week vacations, instead of 1 week. The clients were demanding more bags and up to 40 Kg of luggage weight. They had a choice to increase the size of the plane but the accountants and engineers were concerned because the fuel costs would increase and the safety of the planes may be compromised as well with so much weight. The sales department also voiced an objection that larger planes would cut down on their flying routes leading to less possible destinations clients could visit.

It was known since 2011 a safe and effective solution would be to separate the less critical luggage on a train or boat and the important luggage could go with the client to solve these problems but the airline kept delaying these changes because of distribution and contract problems with the railroad/shipyard companies. Redirecting every railroad or shipping route would be a logistical nightmare. Another concern is passengers didn't want their luggage being mixed or misplaced within the trains/boats as they were keen on some of the new quick luggage check-in and fraud protection processes the airlines were developing and there is no way they could get any of that with dumping their luggage on a train or boat.

One day a bright young engineer recommended a novel approach to solve these concerns. He indicated, "Look, we already have shipping agreements with Fedex/DHL and lease out a certain amount of space on their cargo planes that flyout from the same airports. We would have to increase capacity on them but they are efficient and we won't have to reroute all the trains or deal with the nasty railroad companies and our passengers could still bring their important luggage through our new fraud protection and quick check-in processes. Our passengers won't have to pay more and get everything they want. We will have to secure larger contracts with the airfreight companies but ultimately they will benefit from more business and we will benefit from more flight routes and clients." ... followed by an applause from the board of directors and some quick recommendations to roll out the long awaited changes immediately.



***edited to better explain the complexities and tradeoffs in the analogy.***

Yes, Soft forks are new chains in all cases.



There is only one chain. The softfork would allow old clients and implementations to bloat the blockchain still and the newer clients would prune off the unneeded signatures. You are insinuating that the security model would change introducing potentially new bugs. This is false as the security model remains exactly the same.

The blockchain signatures are segregated-- one has the transactions minus signatures, and one has just the signatures. Full nodes will still download and verify both, so security isn't reduced or compromised .

This is basically creating a better SPV/lite client that has the ability to use fraud proofs for authentication. It is not meant to replace Full nodes!