Segregated Witness legal flaw and its probable technical solutions

[aliashraf]

Recently I read something about legal consequences of segregated witness once it has been adopted by bitcoin. It was something about the fact that SW does not preserve the signature of the payer and the legal consequences of this in cases when the payer denies the authenticity of the transaction, say months or years after it has been confirmed by the network. While it is a controversial legal issue, the probable solutions will be definitively technical.

Let's have a look at the core problem:

1- December 2017, (months after activation of SW) Alice and Bob sign a contract that implies both of them should open  a bitcoin 2-of-2 multisig wallet
   and their mutual business revenues should go there (customers should pay to the multisig wallet). The wallet is made immediately and the
   business starts up.

2- January 2018: After a few btcs accumulates in the wallet worth almost a couple of grands, the partnership ends and they withdraw their shares,
    evenly while shaking their hands.

3- January 2028, a few months after bitcoin has surpassed its historical record of $200K heading for $500K, Alice goes to the court and claims Bob
   has committed a fraud with somehow emptying the wallet without her signature.

4- February 2028: The report prepared by the experts assigned by the court mentions among other points: "There is no signature  of neither
   Alice nor Bob preserved in the bitcoin blockchain that can be used as a proof of their intention and permission for the withdrawal while the wallet
  is emptied almost 10 years ago ...one of the parties (Bob) has admitted that he has signed the withdrawal transaction and Alice denies
    every responsibility". The report Also adds "[While] there is no electronic signature to use as a proof ... it is important to be mentioned explicitly
   that the nodes which verified and confirmed the transaction 'should have seen and approved' such a signature and can be considered as some kind
   of a 'witness' ..."

5- March 2028: The court issues a verdict: "As there is no electronic signature proof 'attached' to the transaction and Bob admits his signature
    being used in the transaction while Alice does not ... this court decides in favor of Alice and against Bob .... The court rejects the feasibility of
    using blockchain nodes as 'witness' as long as this term is exclusively can be used for adult human beings with free will and in the good mental
    health situation".

This is obviously a flaw and its roots are somewhere deep in the SW being a 'hack' and not a descent protocol design. This has leaded to a situation in which there is no room in the blockchain for the SW transactions to have their signatures attached, the way bitcoin currently does it and traditional paper document always have been signed this way, and courts all over the world are used to consider it 'legal'.

But of course SW should be run anyway, considering  all we have gone through in the long, long recent  years. The thing is what we can do about this legal flaw? I mean technically ... or put it this way ... Now that we are hackers more than devs, can we find a complementary 'hack' for SW to take care of this problem?

I have a couple of ideas which I'll share with you very soon. But you are welcome to share yours and take the credit.

[1713987498]

1713987498

[1713987498]

1713987498

[1713987498]

1713987498

[gmaxwell]

This is profoundly and absurdly stupid on several levels.

The simplest of which is your claim that "There is no signature  of neither Alice nor Bob preserved in the bitcoin blockchain": that isn't how segwit works, the signature is inside the transactions, same as it always has been. If it weren't one would simply show the address that was used which the rules of the system make impossible for it to spend from without both parties participation, though this point is moot because the signatures haven't gone anywhere.

Segwit means the signature is not included in the computation of the transaction ID via the same mechanism as they are excluded from the sighash IDs that get signed (after all, a signature can't sign its pubkey and itself).  They are still included in the transaction (and thus, the blocks).

You should spend less time listening to scammers like Craig Wright and NChain-- they will shamelessly misinform you if they see it to their advantage to do so.

[aliashraf]

This is profoundly and absurdly stupid on several levels.

The simplest of which is your claim that "There is no signature  of neither Alice nor Bob preserved in the bitcoin blockchain": that isn't how segwit works, the signature is inside the transactions, same as it always has been. If it weren't one would simply show the address that was used which the rules of the system make impossible for it to spend from without both parties participation, though this point is moot because the signatures haven't gone anywhere.

Segwit means the signature is not included in the computation of the transaction ID via the same mechanism as they are excluded from the sighash IDs that get signed (after all, a signature can't sign its pubkey and itself).  They are still included in the transaction (and thus, the blocks).

You should spend less time listening to scammers like Craig Wright and NChain-- they will shamelessly misinform you if they see it to their advantage to do so.

Well it is not so simple, I wish it was but it is not ...

Once Segregated Witness becomes operational, transmission of signature data ( typically 60% of transaction data) will be optional and It will be up to the nodes to decide to store signature data or not. And who cares about the signature? The one who wants to validate it. But Who wanna validate a transaction signature? I tell you: a very few nodes! {EDIT: for a very short period of time}

Actually right now there are rumors that some pools do not waste their 'valuable' time to check a newly mined block at all, they just pick the hash and create new works based on it.

Now, this is what happens: It is completely possible (and I think unavoidable) for at least old blocks' signatures to get lost in the horizon, as nobody has any incentive to keep them alive, they are just 'not necessary' and waste (a lot of)space.

Craig Wright: he officially gave up being Satoshi, it is more than enough to leave him alone to rest in peace.

NChain: Who is he?

[gmaxwell]

Well it is not so simple, I wish it was but it is not ...

Yes it.

Once Segregated Witness becomes operational, transmission of signature data ( typically 60% of transaction data) will be optional and It will be up to the nodes to decide to store signature data or not. And who cares about the signature? The one who wants to validate it.

Woah. Layered confusion here.   Transmission of the signature data isn't optional, it's _REQUIRED_ by all segwit full nodes.  They have no mechanism to operate without it, nor does any make logical sense for them to not require it.   In particular, at runtime it doesn't take them any bandwidth at all:  Raw blocks haven't been transmitted between nodes at the tip for a long time, instead compact blocks are transferred which use 6 bytes per transaction to reference the already transferred loose transactions, so sending a block without signatures would take more than 25 times the amount of bandwidth used normally when sending blocks on the tip of the chain today.

Now, in terms of _storing_: That is already optional and has always been and hasn't been changed by segwit. Bitcoin nodes support pruning, it's described in section 7 of the Bitcoin whitepaper ("Reclaiming Disk Space")-- you can activate it in any copy of Bitcoin Core by e.g. putting prune=1000 in your configuration  and tada, you won't be storing any signatures past the past couple hundred blocks or so. No segwit involved at all.

So if your concern is that some people might not store signatures-- well that has _always_ been possible,  it is the reality today, and is fundamentally impossible to prevent.  But who gives a darn if some people don't store them?  The block still commits to exactly the signatures that were used and anyone can happily prove which ones were used.

But Who wanna validate a transaction signature? I tell you: a very few nodes!

Bitcoin has always had support for nodes that don't validate things, called "simplified payment verification" and described in section 8 of the whitepaper.

FWIW, Bitcoin "Unlimited" no longer verifies any signatures in blocks where the miner has claimed a timestamp before some number of days ago.  This creates obvious corner case security vulnerabilities but no one seems to care... and they didn't need segwit to do this moronic thing.

Actually right now there are rumors that some pools do not waste their 'valuable' time to check a newly mined block at all, they just pick the hash and create new works based on it.

This is called SPY mining or headers mining (an aborted feature of Bitcoin "Classic") -- what of it?  It doesn't have anything to do with segwit.   It undermines the security assumptions made by lite nodes but doesn't change anything for full nodes.

Now, this is what happens: It is completely possible (and I think unavoidable) for at least old blocks' signatures to get lost in the horizon, as nobody has any incentive to keep them alive, they are just 'not necessary' and waste (a lot of)space.

That just isn't how the software works w/ segwit:  You can't sync up a node unless it can download the complete blocks. Nodes could enable pruning, and if everyone prunes no new nodes can be synced-- unless someone specifies and supports UTXO set based sync, which no one has today. So the situation is exactly the same with and without segwit.  And in both cases, even if those changes happened and no one was keeping signatures you need only have a copy of it yourself (which you will, the transactions are stored in both the senders and receivers wallets)-- and you could happily prove the signature was the signature used to anyone you wanted to prove it to. Even if no one else stored that data.

Craig Wright: he officially gave up being Satoshi, it is more than enough to leave him alone to rest in peace.
NChain: Who is he?

LOL.  No he didn't.  He's still pretending to be Satoshi. He created a nchain to spread his fraud-- including these absurd attacks on segwit, fraudulent patent threats and so on-- to a larger audience.  It's an nchain propaganda piece that you " Recently [...] read" and are repeating.   But perhaps this is no surprise to you:  Your account's second post on Bitcointalk was defending the claim that Craig Write is Satoshi... (and third (Also promoting wrights' fake academic credentials) and forth and fifth and sixth and so on... in fact, strangely, that seems to be the content of most of your posts... and now you "recently read" something that happens to be a Wright manufactured hit-piece against segwit which you're repeating the argument of without attribution.)

[Pieter Wuille]

Validating nodes need to download and verify the signatures. This is true now, and will be true after SegWit.

Validating nodes do not need to keep signatures around after validation. This is true now (pruning), and will be true after SegWit.

Anyone who has a transaction included in the chain can construct a proof that this happened (SPV proof), and this proof includes the signature that was used. This is true now, and will be true after SegWit (using the wtxid merkle tree instead of the txid merkle tree).

[aliashraf]

Validating nodes need to download and verify the signatures. This is true now, and will be true after SegWit.

{Also @GMaxwell can take it as a response as he has almost a same position }
No! It is not an exact description: after SegWit the term 'validation' gets somewhat loose defined. What Kind of validation? To what extent do you want to validate?
Being a 'full node'(Greg's term) or a 'validating node' (yours) is possible without preserving signatures after SegWit and it is not possible right now.
A full node is capable to handle temporary chain splits and to choose the right sequence by checking for double spend and not the signatures. It is what Segwit puts on the table, real working light full nodes.

Validating nodes do not need to keep signatures around after validation. This is true now (pruning), and will be true after SegWit.

{to @GMaxwell as well}
Nah! pruning is about giving up the ability to traceback the blockchain in case of critical splits and forks when one should consider long tracebacks. It is about deleting the whole transaction (fully spent addresses) and preserving (almost) just UTXO. After SegWit we have another option:  ignoring signature part while preserving transactions. It is a different situation.

Anyone who has a transaction included in the chain can construct a proof that this happened (SPV proof), and this proof includes the signature that was used. This is true now, and will be true after SegWit (using the wtxid merkle tree instead of the txid merkle tree).

Well it is a proposal: Keep your proof in your pocket.
A very weak solution. Rejected.

[RocketSingh]

Craig Wright: he officially gave up being Satoshi, it is more than enough to leave him alone to rest in peace.
NChain: Who is he?

LOL.  No he didn't.  He's still pretending to be Satoshi. He created a nchain to spread his fraud-- including these absurd attacks on segwit, fraudulent patent threats and so on-- to a larger audience.  It's an nchain propaganda piece that you " Recently [...] read" and are repeating.

I guess, u mean this - http://www.coindesk.com/the-risks-of-bitcoins-segregated-witness-problems-under-us-contract-law/

Note that, Jimmy Nguyen is chief intellectual property, communications and legal officer for nChain. Interestingly, Jimmy Nguyen is Vietnamese and Craig Wright's Tulip Trust trustee was a Vietnamese lady Uyen T. Nguyen. Rings bell?

[Pieter Wuille]

A full node is capable to handle temporary chain splits and to choose the right sequence by checking for double spend and not the signatures.

That's a nonsensical security model. You're allowing an attacker to take anyone's money with invalid signatures, but not spend it twice? He'll just pay you and then steal the money back. No need for a double spend.

Without the ability to validate signatures, you can effectively not validate any useful property of the system. If that's the model you want, it already exists, and it's called a light client. All SegWit does in this regard is reducing the bandwidth for such nodes. It doesn't change the requirements for nodes that do need to validate.

5- March 2028: The court issues a verdict: "As there is no electronic signature proof 'attached' to the transaction

There is just as much proof in SegWit transactions as in others. The only difference is that it does not contribute to the txid. It's still included in transactions and blocks, it's still required for validation, and it's still committed to.

There is indeed a new storage model possible where someone chooses to delete old signatures but not delete the rest. However (1) there is already no guarantee that nodes keep around everything for you, and if you want proof in the future that a transaction took place you'll need to keep it yourself (which every wallet software does) (2) that new model is only useful for serving light clients that already don't care about the signatures anyway.

[aliashraf]

A full node is capable to handle temporary chain splits and to choose the right sequence by checking for double spend and not the signatures.

That's a nonsensical security model. You're allowing an attacker to take anyone's money with invalid signatures, but not spend it twice? ...

Spending money twice is a long-term, permanent  concern while proof of signature is just a short-term transient one, from the pov of the full/validator node, as long as it comes to incentives and interests in being and remaining a 'full node' capable of participating actively in consensus process.

Historically, this separation of concerns, has been the main invention of SegWit proposal from the first beginning and if you may bother and just check the documentation, you can find a lot of reference to it.

Without the ability to validate signatures, you can effectively not validate any useful property of the system. If that's the model you want, it already exists, and it's called a light client. ...

Nah! current 'light clients' can do nothing about validation other than some trivial and formal checks. Post-SegWit ones , which I strongly believe will be the dominant nodes in the network, are capable of anything a traditional full node can do, including double-spend check.

Let's take a moment and chew it: Current light clients can't check UTXO and prevent double spends, post-SegWit 'semi-ligh' clients can. It is how SegWit encourages this kind of nodes and leaves no incentive to remain a prehistoric fat and resource consuming dinosaur. Clear?

All SegWit does in this regard is reducing the bandwidth for such nodes. It doesn't change the requirements for nodes that do need to validate.

Yes it does! The requirements to validate the integrity of the blocks will be changed radically.

5- March 2028: The court issues a verdict: "As there is no electronic signature proof 'attached' to the transaction

There is just as much proof in SegWit transactions as in others. The only difference is that it does not contribute to the txid. ...

That 'only' difference is a huge one  

When something is discarded from SHA2 process and txId, it is no longer necessary for validating the integrity  of the hashing process and the block header and we just need UTXO to check double spend and become a full node ... Oops! we got a validator node (in your terminology) without any obligation to store the signatures for future use.

[aliashraf]

As I expected before doing such a 'dangerous' thing, starting a topic here in bitcointalk about a flaw in SegWit, the first stage is denial. Guys come here denying any flaw, although it is a natural consequence of the so-called scaling debate, but does not help by any means.

SegWit is nothing more than a hack, a protocol manipulation. We have always good hacks and  bad hacks. For a hack to be classified as good it is definitively not enough to possess good intention and being brilliant. It should have a good support and maintainability as well. Enthusiasm is a good hack killer because it turns it to a rigid piece of code which is not just able to catch up.

As of Segregated Witness it is damn good hack. It solves a lot of problems and malleability challenges, it improves bitcoin scalability and people who are opposing this upgrade are just not constructive. But solving so many problems always has a cost: producing new problems, It is just about trade-off.

The SW's legal flaw problem,I have started this topic about, is not a big deal, by any measure and it is a remarkable achievement   to solve and/or improve so many problems with such a small cost. But the flaw should be fixed like any other flaws in a monetary system.

I strongly recommend instead of denying everything and claiming perfection like some junior programmers obsessed with Satoshi legend, people should better just grow up and observe that there is not and will be not any perfection in the world of programming. It is just about evolution through improvements.

[buwaytress]

Craig Wright: he officially gave up being Satoshi, it is more than enough to leave him alone to rest in peace.
NChain: Who is he?

LOL.  No he didn't.  He's still pretending to be Satoshi. He created a nchain to spread his fraud-- including these absurd attacks on segwit, fraudulent patent threats and so on-- to a larger audience.  It's an nchain propaganda piece that you " Recently [...] read" and are repeating.

I guess, u mean this - http://www.coindesk.com/the-risks-of-bitcoins-segregated-witness-problems-under-us-contract-law/

Note that, Jimmy Nguyen is chief intellectual property, communications and legal officer for nChain. Interestingly, Jimmy Nguyen is Vietnamese and Craig Wright's Tulip Trust trustee was a Vietnamese lady Uyen T. Nguyen. Rings bell?

I like building connections myself but I can't see how two Vietnamese can be linked to each other other than their citizenship. Nguyen is as common a name in Vietnam as Mohamad is in the Middle East. Speaking of Vietnamese links, I've noticed quite a few alts being launched with a handy number of Vietnamese women named on their teams. Enjoying the Mr. Wright spillover?

[aliashraf]

I strongly ask you to avoid off-topic discussions and start another thread if you find your story very important or at least a little funny.

P.S.  It is not!

[aliashraf]

Obviously, I am not among the guys who think SW is bulletproof or a  perfect and exceptional piece of software (I doubt such a 'thing' ever exists) and I feel it is time to go forward by accepting the flaw I have started this thread about, SW's legal flaw and discussing the possible fixes.

But I just wait a little more before sharing my basic idea about how this can be fixed, because it is hard to imagine, sooner or later, @Gmaxwell (with his special style of commenting   )won't show up here denying the existence of such a flaw at all

So we keep the tempo slow beat and just wait. Be patient

[Pieter Wuille]

Let's take a moment and chew it: Current light clients can't check UTXO and prevent double spends, post-SegWit 'semi-ligh' clients can.

The only thing the 'SegWit semi-ligh' client you describe can do is verify that no historical inflation occurred. It cannot be used to verify incoming SegWit payments in a meaningful way beyond what a light client today can do, so it's useless for any economically relevant entity to rely upon.

It is how SegWit encourages this kind of nodes and leaves no incentive to remain a prehistoric fat and resource consuming dinosaur. Clear?

Perfectly clear, but I disagree. Nodes can already prune history, and I think in the future nearly every node will. This does not impact security, as they still download and verify everything. If you feel like running a 'semi-ligh' node which is basically useless, still needs to maintain the full UTXO set (likely the largest resource cost of running a node in the near future), and in return only get a small constant factor of bandwidth reduction, be my guest.

That 'only' difference is a huge one  

No, it's a technicality. The same data is still committed to in the wtxid. It's just moved.

When something is discarded from SHA2 process and txId, it is no longer necessary for validating the integrity  of the hashing process and the block header

This is wrong. The witnesses are committed to by the wtxid, which are included in the witness merkle tree, which is committed to by the coinbase, which contributes to the block header.

You cannot change a witness and expect a block to still be valid, except to your pointless 'semi-ligh' node.

and we just need UTXO to check double spend and become a full node
 ... Oops! we got a validator node (in your terminology) without any obligation to store the signatures for future use.

Again, nodes already don't have any obligation to store signatures (or anything) for future use.

[aliashraf]

This is an unfortunate for me that I live in a very different time zone and right now I'm truly too exhausted to continue this discussion, but will do my best. After all it is a surprise for me that besides @GMaxwell one of the most celeberated contributers of SegWit, @Pieter Wuille , the inventor, simply does not admit that his proposal, which is going to be lunched (hopefully) in few weeks is simply about:

The entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the blockchain state, not to determine it.

By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:

Guess what? These are the exact opening phrases written by the same @Pietre in his BIP 141 document.

Yes @Pietre, I do agree, several problems will be fixed but one problem will be created: the signatures that you think 'in particular are only required to validate the blockchain state '  will loose their immutability for this simple fact that they are not been hashed. right?

I do not understand why should we have any arguments here? It is so obvious: In Segregated Witness we do not 'freeze' signature data and there is no guarantee for this signature to be preserved , signatures will become just a transient passphrase for the transaction to be validated and confirmed. After the block has been confirmed and followed by other miners, all that matters is its role in the blockchain state, in other words, its impact on the UTXO.

After running SegWit there will be an opportunity for the nodes, full nodes, to store just the relevant, immutable transaction data and treat signatures transiently and temporarily as they are no longer hashed and are not immutable.

For now let's just check the integrity of my arguments. Am I in the right direction, @Pietre?

P.S. and forgive me if I can not follow your response immediately, it is getting too late in Iran and I need some rest.

[Pieter Wuille]

Yes @Pietre, I do agree, several problems will be fixed but one problem will be created: the signatures that you think 'in particular are only required to validate the blockchain state '  will loose their immutability for this simple fact that they are not been hashed. right?

The statement above is false. The signatures are still hashed and committed to by blocks. No immutability is lost. If you don't believe me, please read BIP 141 carefully:

A new wtxid is defined: the double SHA256 of the new serialization with witness data:

...

A new block rule is added which requires a commitment to the wtxid.

...

A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.

By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:

The data is removed from the transaction merkle tree, and instead committed to in the witness merkle tree. That witness merkle tree is committed to in the coinbase.

[DannyHamilton]

This is getting to be a bit ridiculous. You have now implied 5 times that signatures are no longer checked when validating blocks, and that there is nothing in the block that prevents a signature from being falsified.  All 5 times, you have been corrected by the people that actually designed and programmed the feature.

If you are going to ignore the things they are telling you, then you are going to need to do a much better job of explaining what they are overlooking.  It's beginning to sound a bit like someone repeatedly insisting that 1 + 1 = 3 without explaining in detail why they believe that, and why 1 + 1 != 2.

In other words, you either need to:

• Take a closer look and see if you are mistakenly believing false information you received from someone else over facts from those that actually know
• Explain exactly why a 'semi-light' client with the same problem can't be created without seg-wit and/or how a seg-wit fully validating node can bootstrap without the signature information.

[aliashraf]

Well, I have to admit that in this thread I have been somewhat immoderate and even reckless and I guess It was @GMaxwell's fault

Seriously Greg, you come here and escalate everything just because what I'm talking about is triggered by someone you know as the 'bad guy'.

I understand it is about 'money', bitcoin is a monetary system, and everything is suspected to be a political game a maneuver, but we have to be cautious, we need criticism and hammering and our "bad, bad, greedy enemies" are welcomed to share with us their ideas and recommendations, IMO.

Anyway, thanks to @Pietre I have to reconsider a couple of issues and will be back soon.

[aliashraf]

Yes @Pietre, I do agree, several problems will be fixed but one problem will be created: the signatures that you think 'in particular are only required to validate the blockchain state '  will loose their immutability for this simple fact that they are not been hashed. right?

The statement above is false. The signatures are still hashed and committed to by blocks. No immutability is lost. If you don't believe me, please read BIP 141 carefully:

A new wtxid is defined: the double SHA256 of the new serialization with witness data:

...

A new block rule is added which requires a commitment to the wtxid.

...

A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.

By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:

The data is removed from the transaction merkle tree, and instead committed to in the witness merkle tree. That witness merkle tree is committed to in the coinbase.

Fair! I now understand, I  overlooked the fact that wtxids have to be committed to the transaction merkle tree indirectly, and this way, they  can provide immutability for the signature data which have been excluded from the primary hash procedure. Thanks for the patience and the reply.

I'm not done yet with the whole problem though as I think this 'detaching process' (detaching data from its signature), has possible consequences  like 'weakening' the incentives for nodes to keep track of the signatures.

It is what I have to analyse a bit more and will share it with you asap.