Segregated witness - The solution to Scalability (short term)?

[franky1]

If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult

What constitutes a full node might change over time, as more advanced features, like UTXO commitments, are implemented. But yes, they are still the bottleneck, and the SW doesn't claim fixing it. The benefits are those listed in the OP, on the picture.

lol.. i love it how a few people are so commited to pointing out the picture but without explanation..
so here is my picture


now tell me..
will it play Call of duty on full res.
will does it have HMDI
is the screen technicolor or just black and white
is the pre-installed windows set to english or japanese.
does it come with a power cable?

yea pictures with list of features can say one thing.. but they dont explain the details people really need.. so can people stop saying 'look at the picture' as it explains nothing

[QuestionAuthority]

If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult

What constitutes a full node might change over time, as more advanced features, like UTXO commitments, are implemented. But yes, they are still the bottleneck, and the SW doesn't claim fixing it. The benefits are those listed in the OP, on the picture.

lol.. i love it how a few people are so commited to pointing out the picture but without explanation..
so here is my picture


now tell me..
will it play Call of duty on full res.
will does it have HMDI
is the screen technicolor or just black and white
is the pre-installed windows set to english or japanese.
does it come with a power cable?

yea pictures with list of features can say one thing.. but they dont explain the details people really need.. so can people stop saying 'look at the picture' as it explains nothing

So, have you posted your concerns on the Bitcoin-dev discussion board yet?

[RoadTrain]

If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult

What constitutes a full node might change over time, as more advanced features, like UTXO commitments, are implemented. But yes, they are still the bottleneck, and the SW doesn't claim fixing it. The benefits are those listed in the OP, on the picture.

lol.. i love it how a few people are so commited to pointing out the picture but without explanation..
so here is my picture
[ img]http://www.amitbhawani.com/blog/wp-content/uploads/2010/04/Olive-Zipbook-3G.jpg[ /img]

now tell me..
will it play Call of duty on full res.
will does it have HMDI
is the screen technicolor or just black and white
is the pre-installed windows set to english or japanese.
does it come with a power cable?

yea pictures with list of features can say one thing.. but they dont explain the details people really need.. so can people stop saying 'look at the picture' as it explains nothing

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

[franky1]

So, have you posted your concerns on the Bitcoin-dev discussion board yet?

once i get home. i will

[franky1]

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

i know splitting the blockchain into 2 is not needed.. SWliteclients can prune what they like how they like without messing with the real blockchain.
i understand the benefits of adding new opcodes..

but the real question is.. how is the fraud proof so special that only SW proposition can implement it. explain how the fraud proof works in your own words

[johnyj]

its all theory but here is a story

mining pools will still be full node
in 2015 a tx looks like [txdata&sig]. in 2016 SW softfork would look like [txdata][sig] to a full node. so no worries about miners (i hope)

but it would only be [txdata] relayed/saved to a SWClient wallet..

what i could then do, is hack your SWClient so that im the only relay node you connect to.
i do this for 4 people just so your not curious about lack of network connects.
so i could make a [txdata] that is satoshi -> franky 50btc.
i send the [txdata] to you all. and because you all have the same [txdata].. you accept it (remember you cant contact a fullnode to check signature as you are in my hacked circle).
i then say 'bob im satoshi's friend as you can see he gave me 50btc,  i want to give you 50btc if you send me 5000LTC or $15,000.' your happy because its a cheap deal and also you think you will get fame for receiving funds originally from satoshi.. afterall the [txdata] shows that the satoshi funds came to me
you agree so i make a new [txdata] that shows franky -> bob.
you also see for other connections with the same [txdata] crediting you with 50btc
you then send me the litecoin/dollar funds..
i release you from my hacked circle, where you realise that the [txdata] is all fake.. and ive just run off with your litecoins or dollars.. all because you did not have the signatures stored to check locally while you were not able to check the real data.

Exactly, and this is just one of the security risk that is possible under the new implementation, and typically an honest dev will barely understand or test how malicious users exploiting the weakness of the system. So the real damage might only happen when the software is in live traffic

[QuestionAuthority]

So, have you posted your concerns on the Bitcoin-dev discussion board yet?

once i get home. i will

Good, please keep us informed. I'd like to know if I'm on the wrong side on this. I'm not really a big fan of throwing money away. It's obvious that something major will be done in 2016 but I'd prefer to not sit out the whole year waiting for the dust to settle.

[brg444]

typically an honest dev will barely understand or test how malicious users exploiting the weakness of the system.

I'm sorry but that's not knowing the thought process of current core devs.

Adversarial environments are all Peter Todd talks about.

[bambou]

typically an honest dev will barely understand or test how malicious users exploiting the weakness of the system.

I'm sorry but that's not knowing the thought process of current core devs.

Adversarial environments are all Peter Todd talks about.

That's what she said.

[RoadTrain]

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

i know splitting the blockchain into 2 is not needed.. SWliteclients can prune what they like how they like without messing with the real blockchain.
i understand the benefits of adding new opcodes..

but the real question is.. how is the fraud proof so special that only SW proposition can implement it. explain how the fraud proof works in your own words

"Have you stopped beating your wife?" Who argues that only SW can implement fraud proofs? It's a neat additional feature that is relatively straighforward to implement with SW.

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated. But there are two types of fraud that we can't compactly prove right now. These are subsidy fraud (inflated fees) and spending from a non-existent input. Pieter Wuille suggests we store additional data with SW, that isn't present with blocks currently, so by having it we can compactly prove these types of fraud. These data are input values, and a 'path' of inputs (original block height containing that input and a position within that block). Once this data is made a consensus rule, full nodes can simply broadcast, say, a message telling you "This input is invalid because it doesn't exist within the block it claims to", then you check that and decide to ignore the chain with this invalid input.

Fraud proofs are still more of a theoretical approach, and will require careful engineering to make them operational. But making all consensus rules compactly provable is a necessary step towards that.

[franky1]

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

i know splitting the blockchain into 2 is not needed.. SWliteclients can prune what they like how they like without messing with the real blockchain.
i understand the benefits of adding new opcodes..

but the real question is.. how is the fraud proof so special that only SW proposition can implement it. explain how the fraud proof works in your own words

"Have you stopped beating your wife?" Who argues that only SW can implement fraud proofs? It's a neat additional feature that is relatively straighforward to implement with SW.

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated. But there are two types of fraud that we can't compactly prove right now. These are subsidy fraud (inflated fees) and spending from a non-existent input. Pieter Wuille suggests we store additional data with SW, that isn't present with blocks currently, so by having it we can compactly prove these types of fraud. These data are input values, and a 'path' of inputs (original block height containing that input and a position within that block). Once this data is made a consensus rule, full nodes can simply broadcast, say, a message telling you "This input is invalid because it doesn't exist within the block it claims to", then you check that and decide to ignore the chain with this invalid input.

Fraud proofs are still more of a theoretical approach, and will require careful engineering to make them operational. But making all consensus rules compactly provable is a necessary step towards that.

or more simply.. if someone has already checked it.. instead of writing in an opcode to say its invalid.. they just dont relay it..
relying on someone else to do checks, to trust them when they say everything is ok, and only double check when they say is wrong seems a little backwards

even right now i can check a tx from back in 2009 and see if its valid just searching the txid....
i agree that adding in the blockheight and tx position of originating confirmed funds in a new unconfirmed tx can make searching the original tx easier.. but if its invalid.. you simply dont relay it.. bt i still dont see this a fraud proofing.. just making the checking mechanism slight faster (microseconds) by having the header and tx index.
i hopefully dont want to see anyone relaying an invalid tx just to tell someone its invalid. and they blindly trust opcodes without checking source.

i think every bitcoin software whether its SPV, SW, LN or core all check every transaction before saving to file or relaying. never should they just see
OP_Check="im legit" and accept it blindly. nor should they ever receive a invalid transaction, thats already been checked as invalid

that said im all for blockheight txindex.. just not the other part

[brg444]

i think every bitcoin software whether its SPV, SW, LN or core all check every transaction before saving to file or relaying.

SPV doesn't check signatures.

relying on someone else to do checks, to trust them when they say everything is ok, and only double check when they say is wrong seems a little backwards

That's actually how a good share of the ecosystem presently operates. What did you think everyone runs a full node?

It seems to me there are fundamentals holes in your understanding that prevent you from making any progress in your comprehension of SW.

[franky1]

i think every bitcoin software whether its SPV, SW, LN or core all check every transaction before saving to file or relaying.

SPV doesn't check signatures.

relying on someone else to do checks, to trust them when they say everything is ok, and only double check when they say is wrong seems a little backwards

That's actually how a good share of the ecosystem presently operates. What did you think everyone runs a full node?

It seems to me there are fundamentals holes in your understanding that prevent you from making any progress in your comprehension of SW.

as i said, i insinuated SPV SHOULD... not does

but anyways,
ive got a full node. and i also have my own lite wallet. and guess what even though my lite wallet doesnt store the blockchain. i still know basic code get it to connect to other nodes and grab that specific blockchain data as and when needed.. id never ever ever blindly trust a unconfirmed tx based purely on how it was presented to me.. i always check txdata against other nodes history.. never would i ever just accept it and pass it on because it said op_check="im legit".

as i said im all for blockheight and txindex to be included in new transactions as it would make things far far easier to check.. but never should anyone just receive a tx and accept it on face value.

and now im more shocked that, with knowing how simple it is to make a lite wallet. why these other spv wallets are being so lazy.. its not rocket science.

businesses should not be running crappy lite versions..
if a business trains their cashiers on how to check if a bank note is counterfeit then the same should be true to bitcoin businesses using any wallet
they should all atleast be running some sort of lite client that checks history.. and that can be done without even needing to store said 7 years data.

[johnyj]

I had a feeling that this solution seems quite sudden and not very well prepared, might because they are afraid of a transaction volume surge during the next rally, but in that case I'd prefer Jeff's approach to simply raise the block size limit, it does not change the code too much and can buy people more time to work on more long term solution

In fact I think even we do nothing, bitcoin still works. People will adjust themselves to their beloved bitcoin and create solutions outside of blockchain to solve the scaling problem. It is a habit that devs always want to do something to prove that they are working, but even as large as FED, considered to be the top wisdom on the planet, what they do is just print a bit more money or print a bit less money, change interest rate by step of 0.25%, nothing more than that, and they did that for decades. When you are commanding a monetary system, every step of change should be extremely cautious and small

I remember one of the core dev said a few month ago that we should wait until the block become full and see how the situation develop and then start to apply measures accordingly, I still think this is a good approach. People won't die because the banks are closed during week end, similarly, if the block become too congested, they will just reduce the transaction frequency and plan their transaction accordingly, that gives us at least 3-4 times of block space to maneuver, at least one years time to react

[jbreher]

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated.

Nope. Still not getting it. A block with all associated signatures already contains everything needed to determine whether or not it is fraudulent.

[RoadTrain]

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated.

Nope. Still not getting it. A block with all associated signatures already contains everything needed to determine whether or not it is fraudulent.

It does, but not everything can be proven fraudulent compactly at the moment, in a way compatible with lightweight clients. Fraud proofs are allowing for a lite client to be aware of bad blocks without fully downloading and verifying them.

By fully verifying the blockchain you are proving that it's valid (good). By using fraud proof you are proving that something is invalid (bad). Notice the difference.

[franky1]

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated.

Nope. Still not getting it. A block with all associated signatures already contains everything needed to determine whether or not it is fraudulent.

It does, but not everything can be proven fraudulent compactly at the moment, in a way compatible with lightweight clients. Fraud proofs are allowing for a lite client to be aware of bad blocks without fully downloading and verifying them.

By fully verifying the blockchain you are proving that it's valid (good). By using fraud proof you are proving that something is invalid (bad). Notice the difference.

no... because full nodes make blocks (via mining pools ofcourse).. and if other users with full nodes see a invalid tx/block.. they ignore it, dont relay it.. end of
the real stupid thing would be to relay a tx/block knowing its bad/wrong..

its a simple concept.

imagine bank notes.. someone hands you a hand written piece of paper with scribbles on it.. you throw it in the bin and tell the person who created to go screw themselves.. you dont accept it. mark it as counterfeit and then hand it out to the next customer..

[RoadTrain]

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated.

Nope. Still not getting it. A block with all associated signatures already contains everything needed to determine whether or not it is fraudulent.

It does, but not everything can be proven fraudulent compactly at the moment, in a way compatible with lightweight clients. Fraud proofs are allowing for a lite client to be aware of bad blocks without fully downloading and verifying them.

By fully verifying the blockchain you are proving that it's valid (good). By using fraud proof you are proving that something is invalid (bad). Notice the difference.

no... because full nodes make blocks (via mining pools ofcourse).. and if other users with full nodes see a invalid tx/block.. they ignore it, dont relay it.. end of
the real stupid thing would be to relay a tx/block knowing its bad/wrong..

its a simple concept.

imagine bank notes.. someone hands you a hand written piece of paper with scribbles on it.. you throw it in the bin and tell the person who created to go screw themselves.. you dont accept it. mark it as counterfeit and then hand it out to the next customer..

The default policy is already not to relay invalid data. But it doesn't help under adversarial circumstances. It doesn't help if there's miner collusion, and you are getting invalid data from them and have no means to know it's invalid. It doesn't help if they are relaying invalid data to you on purpose.

SW with these modifications allows for a more scalable and safe lite node approach, where you verify (perhaps randomly) some percentage of data.

[franky1]

The default policy is already not to relay invalid data. But it doesn't help under adversarial circumstances. It doesn't help if there's miner collision, and you are getting invalid data from them and have no means to know it's invalid. It doesn't help if they are relaying invalid data to you on purpose.

miner collisions are just 2 miners that solved at nearly the same time.. the data isnt invalid, they just solved relatively at the same time. each of these miners wont invalidate their block. its for the other full nodes to check both blocks and when both are valid. then check who solved first. and the not relay the loser..

there is no point marking the loser as invalid and still relaying it.
there is no point in a miner marking their block as invalid. as at the time of solving and relaying to that very first peer, they dont know they lost.
thats for the network to decide

[RoadTrain]

The default policy is already not to relay invalid data. But it doesn't help under adversarial circumstances. It doesn't help if there's miner collision, and you are getting invalid data from them and have no means to know it's invalid. It doesn't help if they are relaying invalid data to you on purpose.

miner collisions are just 2 miners that solved at nearly the same time.. the data isnt invalid, they just solved relatively at the same time. each of these miners wont invalidate their block. its for the other full nodes to check both blocks and when both are valid. then check who solved first. and the not relay the loser..

there is no point marking the loser as invalid and still relaying it.
there is no point in a miner marking their block as invalid. as at the time of solving and relaying to that very first peer, they dont know they lost.
thats for the network to decide

Of course it's collusion, not collision. I made a typo.