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

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

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.

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
[/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.

merklecoin!

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.

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.

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".

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

Congrats Lauda!   

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. 

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

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.

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

Now the one facepalming is me.

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

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

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

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.

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..

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.