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

[franky1]

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

well thats why bitcoin-core is there.. to validate properly.. and drop invalids.... and that should never ever change for bitcoin core.. handing off invalids to other peers once bitcoincore knows its invalid.. is as i said a few times, a rediculous notion.

i would never in my life trust any data coming in on face value. and soo all these litewallets will fail by trusting opcodes to say its valid but never actually checking..

we should not be thinking of way to add more data to a tx/block in full nodes.. just so that litewallets can be lazy and ignorant.
i originally thought segwit would originally be a better lite wallet. but when i started reading that its a medium weight wallet that does no check and takes data on blind faith of who sent it. without checking origins.. i facepalmed

[1715067849]

1715067849

[RoadTrain]

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

well thats why bitcoin-core is there.. to validate properly.. and drop invalids.... and that should never ever change for bitcoin core.. handing off invalids to other peers once bitcoincore knows its invalid.. is as i said a few times, a rediculous notion.

i would never in my life trust any data coming in on face value. and soo all these litewallets will fail by trusting opcodes to say its valid but never actually checking..

we should not be thinking of way to add more data to a tx/block in full nodes.. just so that litewallets can be lazy and ignorant.
i originally thought segwit would originally be a better lite wallet. but when i started reading that its a medium weight wallet that does no check and takes data on blind faith of who sent it. without checking origins.. i facepalmed

Now the one facepalming is me.

[franky1]

Now the one facepalming is me.

miner(dodgytx)opcheck='imlegit' ->RoadchainSWlite -> otherSWlite-> otherSWlite ->otherSWlite -> otherSWlite

roadchain does no checks and on the data and see's the fraudproof opcode 'imlegit'.. and accepts it and relays it on.. now 4 people have dodgy information.. for no reason.. they cant use it but the 2000 people using the SWlite keep passing it on.. all blindly thinking its valid..

miner(dodgytx)opcheck='imlegit' ->frankyFullNode -||BIN||

franky ignores the opcode'imlegit' and checks the real data. see's its really dodgy and deleted it, its not relayed and its business as usual
then waits for a valid block to be solved, checking that and then relaying that only if satisfied the rules are met

[jbreher]

miner(dodgytx)opcheck='imlegit' ->RoadchainSWlite -> otherSWlite-> otherSWlite ->otherSWlite -> otherSWlite

roadchain does no checks and on the data and see's the fraudproof opcode 'itslegit'.. and accepts it and relays it on.. now 4 people have dodgy information.. for no reason.. they cant use it but the 2000 people using the SWlite keep passing it on.. all blindly thinking its valid..

And it's worse, as now it will be essentially free for an attacker to create unbounded numbers of invalid transactions, and the medium-weight SegWit wallets will blindly relay them throughout the network, clogging it up with crap.

[franky1]

miner(dodgytx)opcheck='imlegit' ->RoadchainSWlite -> otherSWlite-> otherSWlite ->otherSWlite -> otherSWlite

roadchain does no checks and on the data and see's the fraudproof opcode 'itslegit'.. and accepts it and relays it on.. now 4 people have dodgy information.. for no reason.. they cant use it but the 2000 people using the SWlite keep passing it on.. all blindly thinking its valid..

And it's worse, as now it will be essentially free for an attacker to create unbounded numbers of invalid transactions, and the medium-weight SegWit wallets will blindly relay them throughout the network, clogging it up with crap.

shhhhhhh i wanted roadchain to realise it all by himself. next time write 'spoilers'

[funkenstein]

Why stop there?  Lets put TXIDs, scriptsigs, and addresses into separate data structures and calculate merkle trees for each.  Now the block chain doesn't need to have ANY of that data in it.  We can SHA256 a cat of all the merkle roots and now every block has 256 bits only!  We can now fit infinite spam in the chain. 

[Vod]

Off-topic: Milestone reached.

Congrats Lauda!   

[marcus_of_augustus]

Why stop there?  Lets put TXIDs, scriptsigs, and addresses into separate data structures and calculate merkle trees for each.  Now the block chain doesn't need to have ANY of that data in it.  We can SHA256 a cat of all the merkle roots and now every block has 256 bits only!  We can now fit infinite spam in the chain. 

many a true word spoken in jest (well ridicule in this case)

[RoadTrain]

Now the one facepalming is me.

miner(dodgytx)opcheck='imlegit' ->RoadchainSWlite -> otherSWlite-> otherSWlite ->otherSWlite -> otherSWlite

roadchain does no checks and on the data and see's the fraudproof opcode 'imlegit'.. and accepts it and relays it on.. now 4 people have dodgy information.. for no reason.. they cant use it but the 2000 people using the SWlite keep passing it on.. all blindly thinking its valid..

miner(dodgytx)opcheck='imlegit' ->frankyFullNode -||BIN||

franky ignores the opcode'imlegit' and checks the real data. see's its really dodgy and deleted it, its not relayed and its business as usual
then waits for a valid block to be solved, checking that and then relaying that only if satisfied the rules are met

You're still not getting it. Your sarcastic tone is completely unjustified and only shows your lack of understanding.

I dunno where you're getting this thing "opcode 'imlegit'", and it looks extremely stupid on your side.

If a verifying node sees a fraudulent block, it constructs a compact fraud proof and relays it instead. The particular mechanism and criteria are not clear yet, but the idea is something like that. DoS protection in necessary anyway.

What you're doing here is making up a stupid non-existent solution that no sane person will accept and then ridicule it. You basically ridicule your own idea

What's more funny is that this whole idea of fraud proofs is present in the Bitcoin Whitepaper under the name 'alerts', in section 8. "Simplified Payment Verification".

As such, the verification is reliable as long as honest nodes control the network, but is more
vulnerable if the network is overpowered by an attacker. While network nodes can verify
transactions for themselves, the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the network. One strategy to
protect against this would be to accept alerts from network nodes when they detect an invalid
block, prompting the user's software to download the full block and alerted transactions to
confirm the inconsistency. Businesses that receive frequent payments will probably still want to
run their own nodes for more independent security and quicker verification.

[Zarathustra]

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,

Yes, they can use Litecoin, Viacoin, Dogecoin, Monero, instead of Bitcoin, where the stream is blocked.
This seems to be a great strategy of the core devs. The Altcoiners should applaud it, and they do.

[Carlton Banks]

You're still not getting it. Your sarcastic tone is completely unjustified and only shows your lack of understanding.

I dunno where you're getting this thing "opcode 'imlegit'", and it looks extremely stupid on your side.

If a verifying node sees a fraudulent block, it constructs a compact fraud proof and relays it instead. The particular mechanism and criteria are not clear yet, but the idea is something like that. DoS protection in necessary anyway.

What you're doing here is making up a stupid non-existent solution that no sane person will accept and then ridicule it. You basically ridicule your own idea

What's more funny is that this whole idea of fraud proofs is present in the Bitcoin Whitepaper under the name 'alerts', in section 8. "Simplified Payment Verification".

As such, the verification is reliable as long as honest nodes control the network, but is more
vulnerable if the network is overpowered by an attacker. While network nodes can verify
transactions for themselves, the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the network. One strategy to
protect against this would be to accept alerts from network nodes when they detect an invalid
block, prompting the user's software to download the full block and alerted transactions to
confirm the inconsistency. Businesses that receive frequent payments will probably still want to
run their own nodes for more independent security and quicker verification.

Exactly.

Mike Hearn and Matt Corallo didn't implement Satoshi's complete idea for SPV in the first place, we've been living with the implications (lower grade security SPV wallets) of that ever since. SegWit completes the design in the original white paper, so all this "re-design" rhetoric is deluded hand-waving.

Still remains to be seen whether SegWit lives up to it's promises IMO. The upcoming public testnet should be interesting in that respect. I'm optimistic, but I also find myself agreeing with those that say to do this as a hard fork. 12 months is a long time in Bitcoin, and a hell of a long time for a fork rollout.

[bambou]

Why stop there?  Lets put TXIDs, scriptsigs, and addresses into separate data structures and calculate merkle trees for each.  Now the block chain doesn't need to have ANY of that data in it.  We can SHA256 a cat of all the merkle roots and now every block has 256 bits only!  We can now fit infinite spam in the chain. 

many a true word spoken in jest (well ridicule in this case)

merklecoin!

[franky1]

ok here is my thought process


(1) is obvious that both fullnodes and SWLite clients will relay data.. please use as a simple reference example to compare to the other 3 theories
remember because SWLite only has 25% data they wont relay TO fullnodes but fullnodes(100% data) can relay to SWLite and other fullnodes

(2) is the idea that when its a dodgy data fullnodes dont relay to anyone. thats the basic rule of bitcoin!!.. if it dont meet protocol rules.. drop it!
but dumb SWlites dont check. leaving the SWlites thinking everything is fine and dandy.. which is something that the
'fraudproof' needs to address as these SWlites are too lazy to confirm themselves and blindly trusting data received.

(3) ignoring the key in the bottom right for a moment imagine the red lines were blocks with an opcode added to say 'its dogdy'.. all other nodes can have the data to double check without having to request more data from fullnodes

because
(4) now use the key in bottom right as you can see in (4) receiving just a alert(red line) and then requesting more data(blackline) is just alot of bandwidth bloat. and this double checking due to alerts would all fall apart if a SWlite does not have a fullnode connected to it, to verify alerts accusation. so would just say fake accusation

so thats why i envisioned opcheck='its legit/dodgy' inside a block(3). as it wouldnt need the black line after an alert.. because the alert would be inside the block.. saving the need for a black line data request.
but that brought me onto the point of bitcoins cardinal rule.. if its dodgy why even relay anything if the recipient isnt going to save it, just dont send it..

now back to (4) for other reasons
yes the alerts have stopped SWlite1,2 and now SWLite1,2 are just alerting their peers, but thats only because SWLite1,2 had fullnodeA connected to them, and SWLiteX,Y,Z had fullnode1

 if there was not a full node to check, as the case is with SWLiteA then they would continue relaying and it would again look like (2) because the SWLites would treat it as a false accusation due to lack of proof..(no fullnode to corroborate data).

so this is why i thought SegWit's solution was to break the cardinal rule of bitcoin. by not dropping the block on rule break and instead keep it, just to allow lazy clients to check(silly i know)

the funny thing is.. if SWLite does have rule checking code to be able to perform actions after alert and request(black line).. as proven in (4) then it can be done right from the start.

so
(5) because SWLites do have the rule checking code, just checking it and dropping it, if its dodgy means:
SWLiteA drops it, SWlite1,2,X,Y,Z has nothing to argue about
fullnodeA drops it, fullnode1,X,Y has nothing to argue about

afterall they fullnode and swlites are all 'listening' to the network and taking in data. where SWLite then just truncate the variables they dont need when saving to file to save space

which is the fundemental rule of bitcoin.. dont relay data that doesnt fit the rules but check data you do receive

and now for your quote of a quote

As such, the verification is reliable as long as honest nodes control the network, but is more
vulnerable if the network is overpowered by an attacker. While network nodes can verify
transactions for themselves, the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the network. One strategy to
protect against this would be to accept alerts from network nodes when they detect an invalid
block, prompting the user's software to download the full block and alerted transactions to
confirm the inconsistency. Businesses that receive frequent payments will probably still want to
run their own nodes for more independent security and quicker verification.

[/quote]

i emboldened the real important part
segwit wants to verify in a very haphazard way (4) when its far quicker to just be (5) knowing your protecting the network at every point.
sending out dodgy data and then alerts and then verifying dodgy data. to then alert new peers who then need to verify said dodgy data.. is just mind bending..
easier to just drop the data and end the endless cycle of bandwidth bloat.

[RoadTrain]

If implemented correctly, there would be little to no bandwidth bloat. It means it would be runnable by low-end hardware, while achieving security higher than current SPV. Those demanding more security would still run full nodes.

[franky1]

If implemented correctly, there would be little to no bandwidth bloat. It means it would be runnable by low-end hardware, while achieving security higher than current SPV. Those demanding more security would still run full nodes.

my theory but from different angle


(1) this is what the fullnode blockchain does.. checks the rules, if violation, drop it dont relay it.. dont alert anyone.. it didnt exist
now
(2) is segwit. it DOES NOT check data at first. but waits for an alert. as you can see SWLiteA alerts the next Swlite1, even though it has confirmed its duff.. the alerts keep happening..SWLite1 alerts SWLiteX who alerts SWLite& and so on and so on endlessly. look at all the extra queries each client is making.

(3) is segwit. that DOES check data at first. as you can see SWLiteA drops the data and doesnt relay.. now the rest of the network does not need to worry or check

[jbreher]

If implemented correctly,

One would hope.

there would be little to no bandwidth bloat.

Unsupported assertion. Could you make a proper defense of this?

It means it would be runnable by low-end hardware,

With the 'low end' that this enables not even saving half over a full node, I rather doubt that many would opt for this unsecure near-full-node. (Thank goodness.)

while achieving security higher than current SPV.

But still insecure.

Those demanding more security would still run full nodes.

This I can agree with.

[RoadTrain]

If implemented correctly, there would be little to no bandwidth bloat. It means it would be runnable by low-end hardware, while achieving security higher than current SPV. Those demanding more security would still run full nodes.

my theory but from different angle
https://i.imgur.com/JOBRymb.jpg

(1) this is what the fullnode blockchain does.. checks the rules, if violation, drop it dont relay it.. dont alert anyone.. it didnt exist
now
(2) is segwit. it DOES NOT check data at first. but waits for an alert. as you can see SWLiteA alerts the next Swlite1, even though it has confirmed its duff.. the alerts keep happening..SWLite1 alerts SWLiteX who alerts SWLite& and so on and so on endlessly. look at all the extra queries each client is making.

(3) is segwit. that DOES check data at first. as you can see SWLiteA drops the data and doesnt relay.. now the rest of the network does not need to worry or check

This is rather far from reality. How do you think block relay works? You don't simply send a full block to everyone. Instead, to every connected node you send a short 'inv' (inventory) message, containing a hash of a block/tx you've just received (and verified). Then, these nodes can request this data from you, if they don't already have it. The point is that you don't know if nodes already have this block, and in order for a block to reach every node, you need this small overhead, you need to tell everyone that you have it.

The same is with alerts. In order for everyone to know about fraud you have to relay it to every node that wants it. I guess it can also be done by firstly notifying nodes with a short inv message. This way the overhead would be comparable to block propagation.

Anyway this is theoretical, I don't know how this will be implemented, there's no formal protocol.

With the 'low end' that this enables not even saving half over a full node, I rather doubt that many would opt for this unsecure near-full-node. (Thank goodness.)

I don't know how you estimated all this, but nevermind.

[franky1]

This is rather far from reality. How do you think block relay works? You don't simply send a full block to everyone. Instead, to every connected node you send a short 'inv' (inventory) message, containing a hash of a block/tx you've just received (and verified). Then, these nodes can request this data from you, if they don't already have it. The point is that you don't know if nodes already have this block, and in order for a block to reach every node, you need this small overhead, you need to tell everyone that you have it.

The same is with alerts. In order for everyone to know about fraud you have to relay it to every node that wants it. I guess it can also be done by firstly notifying nodes with a short inv message. This way the overhead would be comparable to block propagation.

i understand that, i was trying to keep things simple.. rather than waffling.
EG
as you say
1.fullnodeA connect to node fullnode1
2.fullnodeA sends "i have upto blockheight 400,000"
3.fullnode1 only has 399,999, so requests 400,000 from fullnodeA, fullnodeA sends 400,000

now using (1) in previous image where X is 400,001

4.dodgy miner broadcast it has 400,001 height
5.FullnodeA is only at 400,000 so asks for 400,001 from miner and dodgy miner sends 400,001
6.FullnodeA sees rules broken. deletes it and listens for anyone with a valid 400,001 while broadcasting it only has 400,000 still
7.Fullnode1 only has 400,000 and is patiently listening to anyone with a valid 400,001

translate to layman
1.miner sends 400,001 , fullnodeA sees rules broken. deletes it and wont relay it..

sorry, but i was not trying to waffle using 7 lines of jargon. just to make a 1 line point..
i didnt want to have to explain how they handshake and resync the chains.. its errelavant to SWLite checks i just wanted to point out that fullnodes when seeing a dodgy block wont relay it.

i always try to keep things laymans simplified.. as then the general public can get their minds around the concept without waffle.

when talking to people about computer hardware.. i dont say RAM or Harddrive i say short term memory and long term memory, web camera is eyes, mouth is the speaker microphone is the ears,

where some would say
a CMOS webcam is: 640 x 480
a HDwebcam is: 1920 x 1080

i say
a CMOS webcam are: eyes with cataracts
a HDwebcam is: perfect 20:20 vision

im sorry that my explanations are not whitepaper material.. but this is not bitcoin-dev, im glad though that the only thing you can knit pick is my lack of technical jargon and waffle

but as i show in (3) when SWLiteA checks if X block exists.. im not talking about reync standard protocol.. as SWLite will need to do more than just check blockheight..

eg
fullnodeA receives 400,001 hash: h3hdkdfksdlfksjlkfj checks and finds rule is broken, deletes it to say it only has 400,000
fullnodeA receives 400,001 hash: ldpffdp4989df988i from different miner, checks and finds rule is good, stores it and now has 400,001

if i was to confuse people by talking about standard resyncing relationship. they would not understand me saying
SWLiteA asks does fullnodeA have 400,001
as eventually the answer would be yes..

my image was not about resyncing. (checking who has height) it was about a separate check
SWLiteA asks does fullnodeA have 400,001 hash: h3hdkdfksdlfksjlkfj
nope
which if we just done resyncing method you elluded to it would be
SWLiteA asks does fullnodeA have 400,001
yes
so again im sorry i was to simplistic.. and not talking about separate checks and hash's and txindex's etc.. but "does X exist" was much simpler to say

i just didnt bother to explain all the variables SWLite would need to check.

and that is why i didnt want to confuse people by even mentioning the standard resyncing part, and treated it as a different call, purely for easy understandings sake

[johnyj]

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,

Yes, they can use Litecoin, Viacoin, Dogecoin, Monero, instead of Bitcoin, where the stream is blocked.
This seems to be a great strategy of the core devs. The Altcoiners should applaud it, and they do.

When your banks are closed during weekend, do you use Chinese RMB because their banks works during weekend? If you are afraid of being taken over by alt-coins, get some alt-coins, just in case  

As statistics show, most of the users don't spend their bitcoin, simply because they will spend depreciating fiat money first and hold bitcoin to protect them from inflation. If you have $4000 and 10 bitcoin, which one do you spend first?

So, given people mostly purchasing bitcoin for long term saving, then they will purchase once a while and should not be very sensitive to transaction frequency and fee. Also, today there are more and more realtime mobile payment system that charges user 0 fee for instant transactions, it is a waste of time trying to scale bitcoin in order to get close to the speed and cost of any centralized solutions today

Maybe there is a real pressure for pools, exchanges and wallet service providers. But these organizations, being centralized, they should pursue clearing based solution to solve their problem, instead of giving pressure to core devs to let the blockchain serve them: Bitcoin is not designed to serve the institutions but person to person

Let's recheck Gavin' quote here:
"Segregated witness transactions won’t help with the current scaling bottleneck, which is how long it takes a one-megabyte 'block’ message to propagate across the network– they will take just as much bandwidth as before. There are several projects in progress to try to fix that problem (IBLTs, weak blocks, thin blocks, a “blocktorrent” protocol) and one that is already deployed and making one megabyte block propagation much faster than it would otherwise be (Matt Corallo’s fast relay network)."

So, a solution changes nodes' architecture, reduces their security, but does not help to reduce the major bottleneck, why rush with that? It is a smart way of thinking but the involved code change and potential security risk just make it less attractive than simply raise the block size to 2MB to deal with current block size limitation. In fact it is a very long term solution to totally change the bitcoin architecture,  thus require much more time and effort to test

[BitUsher]

https://www.youtube.com/watch?v=NOYNZB5BCHM

Peter Wuille: Segregated witness and its impact on scalability at SF Meetup with more time for questions and clarifications.