{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-03\n📝 Original message:Chris Stewart \u003cchris at suredbits.com\u003e writes:\n\n\u003e I do have some concerns about SIGHASH_NOINPUT, mainly that it does\n\u003e introduce another footgun into the bitcoin protocol with address reuse.\n\u003e It's common practice for bitcoin businesses to re-use addresses. Many\n\u003e exchanges [1] reuse addresses for cold storage with very large sums of\n\u003e money that is stored in these addreses.\n\u003e\n\u003e It is my understanding with this part of BIP118\n\u003e\n\u003e\u003eUsing NOINPUT the input containing the signature no longer references a\n\u003e specific output. Any participant can take a transaction and rewrite it by\n\u003e changing the hash reference to the previous output, without invalidating\n\u003e the signatures. This allows transactions to be bound to any output that\n\u003e matches the value committed to in the witness and whose witnessProgram,\n\u003e combined with the spending transaction's witness returns true.\n\u003e\n\u003e if an exchange were to once produce a digital signature from that cold\n\u003e storage address with a SIGHASH_NOINPUT signature, that signature can be\n\u003e replayed again and again on the blockchain until their wallet is drained.\n\u003e This might be able to mitigated since the signatures commit to outputs,\n\u003e which may be small in value for the transaction that SIGHASH_NOINPUT was\n\u003e used. This means that an exchange could move coins from the address with a\n\u003e larger transaction that spends money to a new output (and presumably pays a\n\u003e higher fee than the smaller transactions).\n\nThanks for sharing your concerns Chris, I do agree that noinput and\nfriends are a very sharp knife that needs to be treated carefully, but\nultimately it's exactly its sharpness that makes it useful :-)\n\n\u003e ### Why does this matter?\n\u003e\n\u003e It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain\n\u003e protocols like Lightning. This gives us the building blocks for enforcing\n\u003e specific offchain states to end up onchain [2].\n\u003e\n\u003e Since this tool is useful, we can presume that it will be integrated into\n\u003e the signing path of large economic entities in bitcoin -- namely exchanges.\n\u003e Many exchanges have specific signing procedures for transactions that are\n\u003e leaving an exchange that is custom software. Now -- presuming wide adoption\n\u003e of off chain protocols -- they will need to have a _second unique signing\n\u003e path that uses SIGHASH_NOINPUT_.\n\u003e\n\u003e It is imperative that this second signing path -- which uses\n\u003e SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that\n\u003e controls an exchanges onchain funds. If this were to happen, fund lost\n\u003e could occur if the exchange is reusing address, which seems to be common\n\u003e practice.\n\nTotally agreed, and as you point out, BIP118 is careful to mandate\nseparate private keys be used for off-chain contracts and that the\noff-chain contract never be mixed with the remainder of your funds. The\nway eltoo uses noinput we selectively open us up to replay attacks\n(because that's what the update mechanism is after all) by controlling\nthe way the transactions can be replayed very carefully, and any other\nuse of noinput would need to make sure to have the same guarantees.\nHowever, once we have separated the two domains, we can simply use a\nseparate (hardened) derivation path from a seed key, and never mix them\nafterwards. We never exchange any private keys, so even leaking info\nacross derived keys is not an issue here.\n\n\u003e This is stated here in BIP118:\n\u003e\n\u003e\u003eThis also means that particular care has to be taken in order to avoid\n\u003e unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be\n\u003e used, unless it is explicitly needed for the application, e.g., it MUST NOT\n\u003e be a default signing flag in a wallet implementation. Rebinding is only\n\u003e possible when the outputs the transaction may bind to all use the same\n\u003e public keys. Any public key that is used in a NOINPUT signature MUST only\n\u003e be used for outputs that the input may bind to, and they MUST NOT be used\n\u003e for transactions that the input may not bind to. For example an application\n\u003e SHOULD generate a new key-pair for the application instance using NOINPUT\n\u003e signatures and MUST NOT reuse them afterwards.\n\u003e\n\u003e This means we need to encourage onchain hot wallet signing procedures to be\n\u003e kept separate from offchain hot wallet signing procedures, which introduces\n\u003e more complexity for key management (two keychains).\n\nThis is already the case: off-chain systems always require access to the\nsigning key in real-time in order to be useful. If any state change is\nperformed in a channel, even just adjusting fees or receiving a payment,\nrequires the signature from the key associated with the channel. With\nhigh security on-chain systems on the other hand you should never have a\nhot key that automatically signs off on transfers without human\nintervention. So I find it unlikely that mandating the on-chain keys to\nbe kept separate from off-chain keys is any harder than what should be\ndone with the current systems.\n\n\u003e One (of the few) upsides of the current Lightning penalty mechanism is that\n\u003e fund loss can be contained to balance of the channel. You cannot do\n\u003e something in the current protocol that will effect your funds outside of\n\u003e that channel. With SIGHASH_NOINPUT, that property changes.\n\nGood point, but if the key hygiene is maintained as detailed in BIP118,\ni.e., off-chain keys must be kept separate from on-chain keys, and that\neach off-chain contract instance uses a separate set of keys, that\nproperty is maintained.\n\nRegards,\nChristian"}