{"type":"rich","version":"1.0","author_name":"npub1u03cz099kt69z9awg232rjvlt34azukpzkkvy5uqv64dj9j5fqtshdnn03","author_url":"https://nostr.ae/npub1u03cz099kt69z9awg232rjvlt34azukpzkkvy5uqv64dj9j5fqtshdnn03","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-01\n📝 Original message:\nI do have some concerns about SIGHASH_NOINPUT, mainly that it does\nintroduce another footgun into the bitcoin protocol with address reuse.\nIt's common practice for bitcoin businesses to re-use addresses. Many\nexchanges [1] reuse addresses for cold storage with very large sums of\nmoney that is stored in these addreses.\n\nIt is my understanding with this part of BIP118\n\n\u003eUsing NOINPUT the input containing the signature no longer references a\nspecific output. Any participant can take a transaction and rewrite it by\nchanging the hash reference to the previous output, without invalidating\nthe signatures. This allows transactions to be bound to any output that\nmatches the value committed to in the witness and whose witnessProgram,\ncombined with the spending transaction's witness returns true.\n\nif an exchange were to once produce a digital signature from that cold\nstorage address with a SIGHASH_NOINPUT signature, that signature can be\nreplayed again and again on the blockchain until their wallet is drained.\nThis might be able to mitigated since the signatures commit to outputs,\nwhich may be small in value for the transaction that SIGHASH_NOINPUT was\nused. This means that an exchange could move coins from the address with a\nlarger transaction that spends money to a new output (and presumably pays a\nhigher fee than the smaller transactions).\n\n### Why does this matter?\n\nIt seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain\nprotocols like Lightning. This gives us the building blocks for enforcing\nspecific offchain states to end up onchain [2].\n\nSince this tool is useful, we can presume that it will be integrated into\nthe signing path of large economic entities in bitcoin -- namely exchanges.\nMany exchanges have specific signing procedures for transactions that are\nleaving an exchange that is custom software. Now -- presuming wide adoption\nof off chain protocols -- they will need to have a _second unique signing\npath that uses SIGHASH_NOINPUT_.\n\nIt is imperative that this second signing path -- which uses\nSIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that\ncontrols an exchanges onchain funds. If this were to happen, fund lost\ncould occur if the exchange is reusing address, which seems to be common\npractice.\n\nThis is stated here in BIP118:\n\n\u003eThis also means that particular care has to be taken in order to avoid\nunintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be\nused, unless it is explicitly needed for the application, e.g., it MUST NOT\nbe a default signing flag in a wallet implementation. Rebinding is only\npossible when the outputs the transaction may bind to all use the same\npublic keys. Any public key that is used in a NOINPUT signature MUST only\nbe used for outputs that the input may bind to, and they MUST NOT be used\nfor transactions that the input may not bind to. For example an application\nSHOULD generate a new key-pair for the application instance using NOINPUT\nsignatures and MUST NOT reuse them afterwards.\n\nThis means we need to encourage onchain hot wallet signing procedures to be\nkept separate from offchain hot wallet signing procedures, which introduces\nmore complexity for key management (two keychains).\n\nOne (of the few) upsides of the current Lightning penalty mechanism is that\nfund loss can be contained to balance of the channel. You cannot do\nsomething in the current protocol that will effect your funds outside of\nthat channel. With SIGHASH_NOINPUT, that property changes.\n\n### A side note\nIn general, i think we should start disallowing uses of the SIGHASH\nprotocols that have unexpected behavior. The classic example of this is\nSIGHASH_SINGLE [3]. I get uneasy about adding more footguns to the\nprotocol, which with current network behavior (address re-use)\nSIGHASH_NOINPUT would be a big one.\n\n\n[1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html\n[2] -\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html\n[3] -\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016048.html\n\nOn Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e With the recently renewed interest in eltoo, a proof-of-concept\n\u003e implementation\n\u003e [1], and the discussions regarding clean abstractions for off-chain\n\u003e protocols\n\u003e [2,3], I thought it might be time to revisit the `sighash_noinput` proposal\n\u003e (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].\n\u003e\n\u003e (sorry for the long e-mail. I wanted to give enough context and describe\n\u003e the\n\u003e various tradeoffs so people don't have to stitch them together from\n\u003e memory. If\n\u003e you're impatient there are a couple of open questions at the bottom)\n\u003e\n\u003e Both proposals are ways to allow rebinding of transactions to new outputs,\n\u003e by\n\u003e adding a sighash flag that excludes the output when signing. This allows\n\u003e the\n\u003e transaction to be bound to any output, without needing a new signature, as\n\u003e long as output script and input script are compatible, e.g., the signature\n\u003e matches the public key specified in the output.\n\u003e\n\u003e BIP-118 is limited to explaining the details of signature verification, and\n\u003e omits anything related to deployment and dependency on other proposals.\n\u003e This\n\u003e was done in order not to depend on bip-taproot which is also in draft-phase\n\u003e currently, and to allow deployment alongside the next version of segwit\n\u003e script. `bip-anyprevout` builds on top of BIP-118, adding integration with\n\u003e `bip-taproot`, chaperone signatures, limits the use of the sighash flag to\n\u003e script path spends, as well as a new pubkey serialization which uses the\n\u003e first\n\u003e byte to signal opt-in.\n\u003e\n\u003e I'd like to stress that both proposals are complementary and not competing,\n\u003e which is something that I've heard a couple of times.\n\u003e\n\u003e There remain a couple of unclear points which I hope we can address in the\n\u003e coming days, to get this thing moving again, and hopefully get a new tool\n\u003e in\n\u003e our toolbox soon(ish).\n\u003e\n\u003e In the following I will quote a couple of things that were discussed during\n\u003e the CoreDev meeting earlier this year, but not everybody could join, and\n\u003e it is\n\u003e important that we engage the wider community, to get a better picture, and\n\u003e I\n\u003e think not everybody is up-to-date about the current state.\n\u003e\n\u003e\n\u003e ## Dangers of `sighash_noinput`\n\u003e\n\u003e An argument I have heard against noinput is that it is slightly less\n\u003e complex\n\u003e or compute intensive than `sighash_all` signatures, which may encourage\n\u003e wallet\n\u003e creators to only implement the noinput variant, and use it indiscrimi-\n\u003e nately. This is certainly a good argument, and indeed we have seen at least\n\u003e one developer proposing to use noinput for all transactions to discourage\n\u003e address reuse.\n\u003e\n\u003e This was also mentioned at CoreDev [6]:\n\u003e\n\u003e \u003e When [...] said he wanted to write a wallet that only used\n\u003e SIGHASH\\_NOINPUT,\n\u003e \u003e that was pause for concern. Some people might want to use\n\u003e SIGHASH\\_NOINPUT as a\n\u003e \u003e way to cheapen or reduce the complexity of making a wallet\n\u003e \u003e implementation. SIGHASH\\_NOINPUT is from a purely procedural point of\n\u003e view\n\u003e \u003e easier than doing a SIGHASH\\_ALL, that's all I'm saying. So you're\n\u003e hashing\n\u003e \u003e less. It's way faster. That concern has been brought to my attention and\n\u003e it's\n\u003e \u003e something I can see. Do we want to avoid people being stupid and shooting\n\u003e \u003e themselves and their customers in the foot? Or do we treat this as a\n\u003e special\n\u003e \u003e case where you mark we're aware of how it should be used and we just try\n\u003e to\n\u003e \u003e get that awareness out?\n\u003e\n\u003e Another issue that is sometimes brought up is that an external user may\n\u003e attempt to send funds to a script that was really part of a higher-level\n\u003e protocol. This leads to those funds becoming inaccessible unless you gather\n\u003e all the participants and sign off on those funds. I don't believe this is\n\u003e anything new, and if users really want to shoot themselves in the foot and\n\u003e send funds to random addresses they fish out of a blockexplorer there's\n\u003e little\n\u003e we can do. What we could do is make the scripts used internally in our\n\u003e protocols unaddressable (see output tagging below), removing this issue\n\u003e altogether.\n\u003e\n\u003e\n\u003e ## Chaperone signatures\n\u003e\n\u003e Chaperone signatures are signatures that ensure that there is no\n\u003e third-party\n\u003e malleability of transactions. The idea is to have an additional signature,\n\u003e that doesn't use noinput, or any of its variants, and therefore needs to be\n\u003e authored by one of the pubkeys in the output script, i.e., one or more of\n\u003e the\n\u003e participants of the contract the transaction belongs to. Concretely in\n\u003e eltoo\n\u003e we'd be using a shared key known to all participants in the eltoo\n\u003e instance, so\n\u003e any participant can sign an update to rebind it to the desired output.\n\u003e\n\u003e Chaperone signatures have a number of downsides however:\n\u003e\n\u003e -   Additional size: both the public key and the signature actually need\n\u003e to be\n\u003e     stored along with the real noinput signature, resulting in transfer,\n\u003e     computational and storage overhead. We can't reuse the same pubkey\n\u003e from the\n\u003e     noinput signature since that'd require access to the matching privkey\n\u003e which\n\u003e     is what we want to get rid of using noinput in the first place.\n\u003e -   Protocols can still simply use a globally known privkey, voiding the\n\u003e     benefit of chaperone signatures, since third-parties can sign again. I\n\u003e     argue that third-party malleability is a subset of first-party\n\u003e     malleability, and we should protect against first-party malleability\n\u003e first\n\u003e     and foremost. My counterparty has the incentive to trick me, a\n\u003e third-party\n\u003e     may not.\n\u003e\n\u003e On the plus side chaperone signatures certainly address the lazy-wallet-dev\n\u003e scenario, and as AJ points out in [bip-anyprevout] we get back the same\n\u003e security guarantees as we had without noinput.\n\u003e\n\u003e From what I remember and the transcript (thanks Kanzure for your awesome\n\u003e work\n\u003e by the way), there was no strong support for chaperone signatures during\n\u003e the\n\u003e meeting [6], but feedback from people that were not present is needed:\n\u003e\n\u003e \u003e if everyone who wanted to use NOINPUT was convinced there was a problem,\n\u003e then\n\u003e \u003e they would pick the right thing, but clearly people aren't. It's not a\n\u003e \u003e foot-gun defense mechanism because it's easily bypassed, and it's easier\n\u003e to\n\u003e \u003e bypass it than to use it. Whereas for tagged outputs, it's that if you\n\u003e want\n\u003e \u003e any NOINPUT then you must tag.\n\u003e\n\u003e\n\u003e ## Output tagging\n\u003e\n\u003e One proposal that I found rather fascinating during the discussion in\n\u003e Amsterdam was that we could achieve the same disincentive to use on\n\u003e non-smart-contract cases by simply making the output scripts\n\u003e unaddressable. This can be done by specifying a version of taproot outputs\n\u003e for\n\u003e which the bech32 addressing scheme simply doesn't have a representation\n\u003e [6]:\n\u003e\n\u003e \u003e The tagged outputs idea is that we don't have NOINPUT ANYPREVOUT\n\u003e supported for\n\u003e \u003e taproot v1 outputs, instead we have a segwit version 16 v16 that supports\n\u003e \u003e taproot. The reason for v16 is that we redefine bech32 to not cover\n\u003e \u003e v16. There's no addresses for this type of output. If you're an exchange\n\u003e and\n\u003e \u003e receive a bech32 address, you declare it invalid. You make it less user\n\u003e \u003e friendly here; and there shouldn't be an address anyway. You might want\n\u003e to see\n\u003e \u003e it on a block explorer, but you don't want to pass it around to anyone.\n\u003e\n\u003e We don't need addresses in our contract constructions because we deal\n\u003e directly\n\u003e with the scripts. This would also have the desired effect of no allowing\n\u003e generic wallets to send to these addresses, or users accidentally sending\n\u003e funds to what was supposed to be a one-off script used internally in the\n\u003e off-chain contract.\n\u003e\n\u003e Notice that this idea was already used by Russell O'Connor when performing\n\u003e a\n\u003e transaction on elements using his new scripting language simplicity\n\u003e [7]:\n\u003e\n\u003e \u003e For this experimental development, we created an improper segwit version,\n\u003e \u003e \"version 31\" for Simplicity addresses. The payload of this segwit\n\u003e version 31\n\u003e \u003e address contains a commitment Merkle root of a Simplicity program to\n\u003e control\n\u003e \u003e the UTXO.\n\u003e\n\u003e The concern with output tagging is that it hurts fungibility, marking\n\u003e outputs\n\u003e used in a contract as such and making them identifiable. But maybe it\n\u003e would be\n\u003e a good idea to create two domains anyway: one for user-addressable\n\u003e destinations which users can use with their general purpose wallets, and\n\u003e one\n\u003e domain for contracts, which users cannot send to directly.\n\u003e\n\u003e This also came up during the CoreDev meeting [ams-coredev]:\n\u003e\n\u003e \u003e these sort of NOINPUT signatures are only things that are within some\n\u003e \u003e application or within some protocol that gets negotiated between\n\u003e participants,\n\u003e \u003e but they don't cross-independent domains where you see a wallet or a\n\u003e protocol\n\u003e \u003e as a kind of domain. You can't tell the difference, is this an address I\n\u003e can\n\u003e \u003e give to someone else or not? It's all scripts, no real addresses. There\n\u003e are\n\u003e \u003e types of outputs that are completely insecure unconditionally; there are\n\u003e \u003e things that are protected and I can give to anyone, you don't want to\n\u003e reuse\n\u003e \u003e it, but there's no security issue from doing so. This is an additional\n\u003e class\n\u003e \u003e that is secure perfectly but only when used in the right way.\n\u003e\n\u003e\n\u003e ## Open questions\n\u003e\n\u003e The questions that remain to be addressed are the following:\n\u003e\n\u003e 1.  General agreement on the usefulness of noinput / anyprevoutanyscript /\n\u003e     anyprevout. While at the CoreDev meeting I think everybody agreed that\n\u003e     these proposals a useful, also beyond eltoo, not everybody could be\n\u003e     there. I'd therefore like to elicit some feedback from the wider\n\u003e community.\n\u003e 2.  Is there strong support or opposition to the chaperone signatures\n\u003e     introduced in anyprevout / anyprevoutanyscript? I think it'd be best to\n\u003e     formulate a concrete set of pros and contras, rather than talk about\n\u003e     abstract dangers or advantages.\n\u003e 3.  The same for output tagging / explicit opt-in. What are the advantages\n\u003e and\n\u003e     disadvantages?\n\u003e 4.  Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the\n\u003e     confusion and make for simpler discussions in the end.\n\u003e 5.  Anything I forgot to mention :-)\n\u003e\n\u003e Cheers,\n\u003e Christian\n\u003e\n\u003e [1] \u003c\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002131.html\n\u003e \u003e\n\u003e [2] \u003c\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017285.html\n\u003e \u003e\n\u003e [3] \u003c\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html\n\u003e \u003e\n\u003e [4] \u003chttps://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki\u003e\n\u003e [5] \u003c\n\u003e https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki\n\u003e \u003e\n\u003e [6] \u003c\n\u003e http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/\n\u003e \u003e\n\u003e [7] \u003chttps://lists.ozlabs.org/pipermail/simplicity/2019/000018.html\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191001/6260f1ba/attachment-0001.html\u003e"}