Bitcoin price isn't moving oh no!!! You know WHAT ELSE isn't moving?? SIGHASH_NOINPUT that's what!!!Now as you should already know, Decker-Russell-Osuntokun ("eltoo") just ain't possible without SIGHASH_NOINPUT of some kind or other. And Decker-Russell-Osuntokun removes the toxic waste problem (i.e. old backups of your Poon-Dryja LN channels are actively dangerous and could lose your funds if you recover from them, or worse, your most hated enemy could acquire copies of your old state and make you lose funds). Decker-Russell-Osuntokun also allows multiparticipant offchain cryptocurrency update systems, without the drawback of a large unilateral close timeout that Decker-Wattenhofer does, making this construction better for use at the channel factory layer.Now /u/cdecker already wrote a some code implementing SIGHASH_NOINPUT before, which would make it work in current pre-SegWit P2PKH, P2SH, as well as SegWit v0 P2WPKH and P2WSH. He also made and published BIP 118.But as is usual for Bitcoin Core development, this triggered debate, and thus many counterproposals were made and so on. Suffice it to say that the simple BIP 118 looks like it won't be coming into Bitcoin Core anytime soon (or possibly at all).First things first: This link contains all that you need to know, but hey, maybe you'll find my take more amusing.So let's start with the main issue.Signature Replay AttackSIGHASH_NOINPUT basically means "I am authorizing the spend of any coin of this particular value protected by my key, to be spent to these addresses".Of note is that the default SIGHASH_ALL means "I am authorizing the spend of this particular coin of this particular value protected by my key, to be spent to these addresses".So suppose you were to engage in address reuse. This is highly discouraged behavior, but people are people, people are lazy, and etc. etc. In practice it happens.Now suppose you had two deposits of equal size, in the same address that you have been reusing.Now further suppose that for some reason, your wallet signs using SIGHASH_NOINPUT only. /u/luke-jr has even promised to write one when SIGHASH_NOINPUT is implemented, so you don't even need to go search for one, you just pester /u/luke-jr to release it.So you got two UTXOs, of equal value, to the same address.You spend one UTXO, signing with SIGHASH_NOINPUT, to pay /u/almkglor because he's so awesome at explaining Bitcoin things and deserves to be paid for it./u/almkglor realizes you've used SIGHASH_NOINPUTand that you engaged in address reuse. He writes a new transaction spending your other UTXO of same value and same address, reusing the same signature ("Signature Replay") that was publicly attached to your previous tx. The signature authorizes the spend of any coin protected by that key.Since /u/luke-jr is strongly against address reuse, he will just LOL at you for doing address reuse with his wallet software and mark your bugreports with wontfix, gendopose, allaccordingtothescenario.The above is the Signature Replay Attack, and the reason why SIGHASH_NOINPUT has triggered debate as to whether it is safe at all and whether we can add enough stuff to it to ever make it safe.Now of course you could point to SIGHASH_NONE which is even worse because all it does is say "I am authorizing the spend of this particular coin of this particular value protected by my key" without any further restrictions like which outputs it goes to. But then SIGHASH_NONE is intended to be used to sacrifice your money to the miners, for example if it's a dust attack trying to get you to spend, so you broadcast a SIGHASH_NONE signature and some enterprising miner will go get a bunch of such SIGHASH_NONE signatures and gather up the dust in a transaction that pays to nobody and gets all the funds as fees. And besides; even if we already have something you could do stupid things with, it's not a justification for adding more things you could do stupid things with.So yes, SIGHASH_NOINPUT makes Bitcoin more powerful. Now, Bitcoin is a strong believer in "Principle of Least Power". So adding more power to Bitcoin via SIGHASH_NOINPUT is a violation of Principle of Least Power, at least to those arguing to add even more limits to SIGHASH_NOINPUT.I believe /u/nullc is one of those who strongly urges for adding more limits to SIGHASH_NOINPUT, because it distracts him from taking pictures of his autonomous non-human neighbor, a rather handsome gray fox, but also because it could be used as the excuse for the next MtGox, where a large exchange inadvertently pays to SIGHASH_NOINPUT-using addresses and becomes liable/loses track of their funds when signature replay happens.Output TaggingMaking SIGHASH_NOINPUT safer by not allowing normal addresses use it.Basically, we have 32 different SegWit versions. The current SegWit addresses are v0, the next version (v1) is likely to be the Schnorr+Taproot+MAST thing.What output tagging proposes is to limit SegWit version ranges from 0->15 in the bech32 address scheme (instead of 0->31 it currently has). Versions 16 to 31 are then not valid bech32 SegWit addresses and exchanges shouldn't pay to it.Then, we allow the use of SIGHASH_NOINPUT only for version 16. Version 16 might very well be Schnorr+Taproot+MAST, with a side serving of SIGHASH_NOINPUT.This is basically output tagging. SIGHASH_NOINPUT can only be used if the output is tagged (by paying to version 16 SegWit) to allow it, and addresses do not allow outputs to be tagged as such, removing the potential liability of large custodial services like exchanges.Now, Decker-Russell-Osuntokun channels have two options:Make the funding txo pay to a version 16 SegWit.Make the funding txo pay to a version 0/1 SegWit.The tradeoffs in this case are:If the funding txo pays to a version 16 SegWit, then anyone analyzing the blockchain can point at a version 16 SegWit txo and conclude it was used for the Lightning Network, because seriously, there's little other use for SIGHASH_NOINPUT other than that (well there's certain limited kinds of vault-like constructions, but for the most part, the balance of probability will be that it's a LN channel).Of note is that even non-published channels will likely be trackable via the funding txo paying to version 16 SegWit, which is published onchain.Also, current already-closed published Poon-Dryja channels, that are closed by mutual close instead of unilateral, are indistinguishable onchain from ordinary spends. Trackers that want to keep track of Lightning usage need to store the information themselves, about such published channels that have been closed; the LN won't store it for them, so that at least moves the burden of storing that information to the surveillors, and fuck them anyway.If the funding txo pays to a version 0/1 SegWit, then in the unilateral case we need to have an additional transaction that takes the funding txo and pays to a version 16 SegWit. This adds more overhead in the unilateral close case, and unilateral close in Decker-Russell-Osuntokun already needs two txes (an update and settlement tx); this adds one more tx, a "converter" from version 0/1 SegWit to version 16 SegWit.This lets mutual closes indistinguishable from ordinary spends onchain. Unilateral closes are still obvious, but even today in the Poon-Dryja world unilateral closes are plenty darn obvious (very specific SCRIPT templates are used).The latter tradeoff is probably what would be taken (because we're willing to pay for privacy) if Bitcoin Core decides in favor of tagged outputs.Another issue here is --- oops, P2SH-Segwit wrapped addresses. P2SH can be used to wrap any SegWit payment script, including payments to any SegWit version, including v16. So now you can sneak in a SIGHASH_NOINPUT-enabled SegWit v16 inside an ordinary P2SH that wraps a SegWit payment. One easy way to close this is just to disallow P2SH-SegWit from being valid if it's spending to SegWit version >= 16.Chaperone SignaturesClosing the Signature Replay Attack by adding a chaperone.Now we can observe that the Signature Replay Attack is possible because only one signature is needed, and that signature allows any coin of appropriate value to be spent.Adding a chaperone signature simply means requiring that the SCRIPT involved have at least two OP_CHECKSIG operations. If one signature is SIGHASH_NOINPUT, then at least one other signature (the chaperone) validated by the SCRIPT should be SIGHASH_ALL.This is not so onerous for Decker-Russell-Osuntokun. Both sides can use a MuSig of their keys, to be used for the SIGHASH_NOINPUT signature (so requires both of them to agree on a particular update), then use a shared ECDH key, to be used for the SIGHASH_ALL signature (allows either of them to publish the unilateral close once the update has been agreed upon).Of course, the simplest thing to do would be for a BOLT spec to say "just use this spec-defined private key k so we can sidestep the Chaperone Signatures thing". That removes the need to coordinate to define a shared ECDH key during channel establishment: just use the spec-indicated key, which is shared to all LN implementations.But now look at what we've done! We've subverted the supposed solution of Chaperone Signatures, making them effectively not there, because it's just much easier for everyone to use a standard private key for the chaperone signature than to derive a separate new keypair for the Chaperone.So chaperone signatures aren't much better than just doing SIGHASH_NOINPUT by itself, and you might as well just use SIGHASH_NOINPUT without adding chaperones.I believe /u/ajtowns is the primary proponent of this proposal.Toys for the Big BoysThe Signature Replay Attack is Not A Problem (TM).This position is most strongly held by /u/RustyReddit I believe (he's the Rusty Russell in the Decker-Russell-Osuntokun). As I understand it, he is more willing to not see SIGHASH_NOINPUT enabled, than to have it enabled but with restrictions like Output Tagging or Chaperone Signatures.Basically, the idea is: don't use SIGHASH_NOINPUT for normal wallets, in much the same way you don't use SIGHASH_NONE for normal wallets. If you want to do address reuse, don't use wallet software made by /u/luke-jr that specifically screws with your ability to do address reuse.SIGHASH_NOINPUT is a flag for use by responsible, mutually-consenting adults who want to settle down some satoshis and form a channel together. It is not something that immature youngsters should be playing around with, not until they find a channel counterparty that will treat this responsibility properly. And if those immature youngsters playing with their SIGHASH_NOINPUT flags get into trouble and, you know, lose their funds (as fooling around with SIGHASH_NOINPUT is wont to do), well, they need counseling and advice ("not your keys not your coins", "hodl", "SIGHASH_NOINPUT is not a toy, but something special, reserved for those willing to take on the responsibility of making channels according to the words of Decker-Russell-Osuntokun"...).ConclusionDunno yet. It's still being debated! So yeah. SIGHASH_NOINPUT isn't moving, just like Bitcoin's price!!! YAAAAAAAAAAAAAAAAAAA. via /r/Bitcoin http://bit.ly/2Jm1jHF
No comments :
Post a Comment