Published on: 2016-03-02T22:36:27+00:00
Rusty Russell, a developer for the Bitcoin Lightning Network, discussed the advantages of using SIGHASH_NOINPUT over pre-signed transactions. He mentioned that without SIGHASH_NOINPUT, each commit transaction adds 50 bytes per commit transaction. However, with SIGHASH_NOINPUT, there is only a need to send the timeout/rval per new HTLC. The addition of 70 bytes of signature data for every HTLC for every commitment creates a 70% increase in storage requirements. It is unclear what size a "TCP packet" actually is these days and whether it is 65kB or 1500B. 1500 bytes only allows for about 14 HTLCs open on a channel simultaneously. High volume users are suggested to run their own bitcoin node, while low volume channels can be managed with just 21MB of storage for six months of full transactions.Rusty Russell also mentioned that SIGHASH_NOINPUT isn't very useful for end users running lightning on their phones as they won't be forwarding many transactions. Sending information to a third party who's doing transaction reclaiming might hurt privacy slightly, but it's not a big problem. The 4-byte commitment index can be avoided by encoding it in the commitment transaction's locktime, but the HTLC timeouts still need to be stored/sent. MAST is not useful because it only trades 32+4 bytes of R+timeout for 32 bytes of unknown-AST-hash. A "script is one of these hashes" form would bloat the UTXO set and is unlikely to be acceptable until lightning is the main bitcoin user.In another discussion, Rusty Russell and A. J. Towns discussed the need for timeout and rhash values to build a script to redeem HTLC outputs that are p2sh. They also talked about how pre-signed transactions require sending signatures for each HTLC dealt with, which can become burdensome with many active channels. They mentioned ideas like including more information in the scriptPubKey or using a multiple-choice P2SH to improve the process. However, having visible scriptPubKey with SegWit where R is obvious is not possible anymore. The discussion ended with suggestions for merkelized abstract syntax trees or a new double-length script hash type.Joseph Poon discussed the need for transactions that can encompass all prior states in a compact way. Currently, this is not possible with SegWit transactions due to the cost of storing previous signatures. He suggested including the entire redeemscript or using a multiple-choice P2SH to include the timeout and rhash values needed to build the script to redeem HTLC outputs. This would require putting more information in the scriptPubKey. Developers have proposed the implementation of a new script type for bitcoin transactions to increase flexibility and scalability. The proposal suggests conducting three transactions: an anchor transaction, a commitment transaction, and a penalty transaction. The anchor transaction would involve a single output spendable by 2-of-2 multisig, while the commitment transaction would have several outputs including payment to both parties, time-based multi-sig transactions, and HTLCs. The penalty transaction would include all the outputs from the commitment transaction and have two outputs, one paying to the source of the penalty transaction and the other serving as an outsourcing fee. The developers also discussed the issue of deploying a without-inputs SIGHASH flag and highlighted the vulnerability to replay attacks with the proposal.In an email conversation, Joseph Poon and Bryan Bishop discussed SIGHASH flag types. Poon plans to consider other proposals for the BIP while drafting it for the Lightning Network, but he is cautious about proposing too much flexibility before there are clear use cases. He believes that SegWit resolves malleability without worrying about replay attacks in the event of key reuse. The new sighash flag should only be used if its features are needed.Joseph Poon also discussed SIGHASH_NOINPUT, a SIGHASH flag that excludes the outpoint being spent or the amount as part of the signature but includes the spent outpoint's script. Various proposed SIGHASH types and a draft implementation of SIGHASH_NOINPUT were provided in the email.
Updated on: 2023-07-31T18:52:17.846799+00:00