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