Re: [bitcoin-dev] Taproot proposal
Hi, > A Taproot output is a SegWit output [...] with > version number 1, and a 33-byte witness program whose first byte is 0 or 1. Given a secret key k and public key P=(x,y), a signer with the knowledge of k can sign for -P=(x,p-y) since -k is the secret key for that point. Encoding the y value of the public key therefore adds no security. As an alternative to providing the y value of the taproot output key Q when constructing the taproot output, the signer can provide it when signing. We can also restrict the y value of the internal key P to be even (or high, or a quadratic residue). That gives us 4 options for how to set the y signs for P and Q. 1. Q sign is explictly set in the witness program, P sign is explicitly set in the control block => witness program is 33 bytes, 32 possible leaf versions (one for each pair of 0xc0..0xff) 2. Q sign is explictly set in the witness program, P sign is implicitly even => witness program is 33 bytes, 64 possible leaf versions (one for each 0xc0..0xff) 3. Q sign is explictly set in the control block, P sign is explicitly set in the control block => witness program is 32 bytes, 16 possible leaf versions (one for each 4-tuple of 0xc0..0xff) 4. Q sign is explictly set in the control block, P sign is implicitly even => witness program is 32 bytes, 32 possible leaf versions (one for pair of 0xc0..0xff) The current proposal uses (1). Using (3) or (4) would reduce the size of a taproot output by one byte to be the same size as a P2WSH output. That means that it's not more expensive for senders compared to sending to P2WSH. (Credit to James Chiang for suggesting omitting the y sign from the public key and to sipa for pointing out the 4 options above) > (native or P2SH-nested, see BIP141) I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for segwit v0 for compatibility reasons. Most wallets/exchanges/services now support sending to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and that will be even more true if Schnorr/Taproot activate in 12+ months time. On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello everyone, > > Here are two BIP drafts that specify a proposal for a Taproot > softfork. A number of ideas are included: > > * Taproot to make all outputs and cooperative spends indistinguishable > from eachother. > * Merkle branches to hide the unexecuted branches in scripts. > * Schnorr signatures enable wallet software to use key > aggregation/thresholds within one input. > * Improvements to the signature hashing algorithm (including signing > all input amounts). > * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support > batch validation. > * Tagged hashing for domain separation (avoiding issues like > CVE-2012-2459 in Merkle trees). > * Extensibility through leaf versions, OP_SUCCESS opcodes, and > upgradable pubkey types. > > The BIP drafts can be found here: > * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki > specifies the transaction input spending rules. > * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki > specifies the changes to Script inside such spends. > * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki > is the Schnorr signature proposal that was discussed earlier on this > list (See > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html > ) > > An initial reference implementation of the consensus changes, plus > preliminary construction/signing tests in the Python framework can be > found on https://github.com/sipa/bitcoin/commits/taproot. All > together, excluding the Schnorr signature module in libsecp256k1, the > consensus changes are around 520 LoC. > > While many other ideas exist, not everything is incorporated. This > includes several ideas that can be implemented separately without loss > of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT, > which we're working on as an independent proposal. > > The document explains basic wallet operations, such as constructing > outputs and signing. However, a wide variety of more complex > constructions exist. Standardizing these is useful, but out of scope > for now. It is likely also desirable to define extensions to PSBT > (BIP174) for interacting with Taproot. That too is not included here. > > Cheers, > > -- > Pieter > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
> * I do not think CoinJoin is much improved by this opcode. > Typically, you would sign off only if one of the outputs of the CoinJoin transaction is yours, and this does not really improve this situation. Coinjoin benefits a lot I think. Coinjoin is improved because you can fit more users into the protocol and create many more outputs at lower cost or include more participants. Ideally a coinjoin creates a lot of outputs so that the ownership is smeared more, but this has a cost at the time of the coinjoin. Coinjoin is also improved because you don't reveal the outputs created by the coinjoin until some time, perhaps very far in the future, when you need the coin. In fact, you only need to reveal where you're moving the coins to participants in your subtree because participants need only verify their branch. It also makes the protocol more stable with respect to input choice. This is because, similar to how NOINPUT may work, OP_COSHV outputs are spendable without knowing what the TXID will be. Therefore if someone changes their input or non segwit spend script, it won't break the presigned txns. This also means that all the inputs can be ANYONECANPAY, so there is no need to reveal your inputs before anyone else. This culminates in being able to open channels from a coinjoin safely, I believe this is difficult/impossible to do currently. > * Using this for congestion control increases blockchain usage by one TXO and one input, ending up with *more* bytes onchain, and a UTXO that will be removed later in (we hope) short time. > I do not know if this is a good idea, to increase congestion by making unnecessary intermediate transaction outputs, at times when congestion is a problem. This is a good idea because it improves QoS for most users. For receiving money pending spendable but confirmed payment (i.e. certified checks) is superior to having unconfirmed funds. For sending money, being able to clear all liabilities in a single txn decreases business exposure to fee variance and confirmation time variance. E.g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day late. If I have 10,000 employees this might be painful if fees are currently up. It also helps to have a backlog of low priority txns to support the fee market. Overall block bandwidth utilization is fairly spikey, so having long term well known outputs that are not time sensitive can be used to better utilize bandwidth. The total extra bandwidth btw is really small given the expansion factor optimizations available. > * I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain update mechanism) on top of this opcode, so I cannot support replacing `SIGHASH_NOINPUT` with this opcode. > In particular, while the finite loop support by this opcode appears (at first glance) to be useable as the "stepper" for an offchain update mechanism, I cannot find a good way to short-circuit the transaction chain without `SIGHASH_NOINPUT` anyway. I'm not deeply familiar with DRO channels. This opcode isn't a replacement for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contrast using SIGHASH_NOINPUT for the uses presented in this BIP. Lastly there's no 'replacing'. Neither NOINPUT nor COSHV are accepted by the community at large yet, and they do different things. > * Channel factories created by this opcode do not, by themselves, support updates to the channel structure. > But such simple "close only" channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign in order to enter the factory). I'm not really an expert at Bitcoin Lightning, but this basic mechanism should work. Imagine the script at a leaf node: Taproot([Alice, Bob], [OP_COSHV ] where uncooperative script is: Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV ) Cooperative closing skips the extra transactions. Updates are signed against the uncooperative script with repudation. E.g.: HASH160 EQUAL IF ELSE "1 week" CHECKSEQUENCEVERIFY DROP ENDIF CHECKSIG It can even be optimized by letting the uncooperative script branches in the leaf be blaming Alice or Bob. Does that not work? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
Good morning, Some more comments. * I do not think CoinJoin is much improved by this opcode. Typically, you would sign off only if one of the outputs of the CoinJoin transaction is yours, and this does not really improve this situation. * Using this for congestion control increases blockchain usage by one TXO and one input, ending up with *more* bytes onchain, and a UTXO that will be removed later in (we hope) short time. I do not know if this is a good idea, to increase congestion by making unnecessary intermediate transaction outputs, at times when congestion is a problem. * I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain update mechanism) on top of this opcode, so I cannot support replacing `SIGHASH_NOINPUT` with this opcode. In particular, while the finite loop support by this opcode appears (at first glance) to be useable as the "stepper" for an offchain update mechanism, I cannot find a good way to short-circuit the transaction chain without `SIGHASH_NOINPUT` anyway. * Channel factories created by this opcode do not, by themselves, support updates to the channel structure. But such simple "close only" channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign in order to enter the factory). More complex channel factories that can update the division of the factory to channels cannot be done without a multiparty offchain update mechanism such as Decker-Wattenhofer or Decker-Russell-Osuntokun. So, similarly to CoinJoin, I do not think it is much improved by this opcode. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, May 22, 2019 1:11 PM, Jeremy wrote: > Morning, > > Yes, in general, Bitcoin does not do anything to prevent users from > discarding their keys. > > I don't think this will be fixed anytime soon. > > There are some protocols where, though, knowing that a key was once known to > the recipients may make it legally valid to inflict a punitive measure (e.g., > via HTLC), whereas if the key was never known that might be a breach of > contract for the payment provider. > > Best, > > Jeremy > > On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj wrote: > > > Good morning Jeremy, > > > > >If a sender needs to know the recipient can remove the covenant before > > >spending, they may request a signature of an challenge string from the > > >recipients > > > > The recipients can always choose to destroy the privkey after providing the > > above signature. > > Indeed, the recipients can always insist on not cooperating to sign using > > the taproot branch and thus force spending via the > > `OP_CHECKOUTPUTSHASHVERIFY`. > > > > Regards, > > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
Morning, Yes, in general, Bitcoin does not do anything to prevent users from discarding their keys. I don't think this will be fixed anytime soon. There are some protocols where, though, knowing that a key was once known to the recipients may make it legally valid to inflict a punitive measure (e.g., via HTLC), whereas if the key was never known that might be a breach of contract for the payment provider. Best, Jeremy On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj wrote: > Good morning Jeremy, > > >If a sender needs to know the recipient can remove the covenant before > spending, they may request a signature of an challenge string from the > recipients > > The recipients can always choose to destroy the privkey after providing > the above signature. > Indeed, the recipients can always insist on not cooperating to sign using > the taproot branch and thus force spending via the > `OP_CHECKOUTPUTSHASHVERIFY`. > > Regards, > ZmnSCPxj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
Good morning Jeremy, >If a sender needs to know the recipient can remove the covenant before >spending, they may request a signature of an challenge string from the >recipients The recipients can always choose to destroy the privkey after providing the above signature. Indeed, the recipients can always insist on not cooperating to sign using the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHVERIFY`. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
Anthony Towns via bitcoin-dev writes: > Hi everybody! > > Here is a followup BIP draft that enables SIGHASH_ANYPREVOUT and > SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. (This is NOINPUT, > despite the name change) I really like this proposal, and am impressed with how cleanly it separated from taproot/tapscript. I believe the chaparone signature requirement should be eliminated: I am aware of four suggested benefits, which I don't believe are addressed adaquately enough by chaparones to justify enshrining this complexity into the protocol. 1. "These features could be used dangerously, and chaparone signatures make them harder to use, thus less likely to be adopted by random wallet authors." This change is already hard to implement, even once you're on v1 segwit; you can't just use it with existing outputs. I prefer to change the bip introduction to expliclty shout "THESE SIGNATURE HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it SIGHASH_UNSAFE_ANYPREVOUT. 2. "Accidental key reuse can make this unsafe." This is true, but chaparones don't seem to help. The main purpose of ANYPREV is where you can't re-sign; in particular, in lightning you are co-signing with an untrusted party up-front. So you have to share the chaparone privkeys with one untrusted party. The BIP says "SHOULD limit the distribution of those private keys". That seems ridiculously optimistic: don't tell the secret to more than *one* untrusted party? In fact, lightning will also need to hand chaparone keys to watchtowers, so we'll probably end up using some fixed known secret. 3. "Miners can reorg and invalidate downstream txs". There's a principle (ISTR reading it years ago from Greg Maxwell?) that if no spender is malicious, a transaction should generally not become invalid. With ANYPREV, a miner could reattach a transaction during a reorg, changing its txid and invalidating normal spends from it. In practice, I believe this principle will remain just as generally true with ANYPREV: 1. For lightning the locktime will be fairly high before these txs are generally spendable. 2. Doing this would require special software, since I don't see bitcoin core indexing outputs to enable this kind of rewriting. 3. We already added such a common possibility with RBF, but before I brought it up I don't believe anyone realized. We certainly haven't seen any problems in practice, for similar practical reasons. 4. "Rebinding is a new power in bitcoin, and it makes me uncomfortable". I have a degree of sympathy for this view, but objections must be backed in facts. If we don't understand it well enough, we should not do it. If we do understand it, we should be able to point out real problems. Finally, it seems to me that chaparones can be opt-in, and don't need to burden the protocol. Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
I agree a little bit, but I think that logic is somewhat infectious. If we're going to do covenants, we should also do it as a part of a more comprehensive new scripting system that gives us other strong benefits for our ability to template scripts. And so on. I'm excited to see what's possible! Given that this is very simple to implement and has obvious deployable big wins with few controversial drawbacks, it makes more sense to streamline adoption of something like this for now and work on a more comprehensive solution without urgency. The design is also explicitly versioned so short of an eventual full redesign it should be easy enough to add more flexible features piecemeal as they come up and their use cases are strongly justified as I have shown here for certified post dated utxo creation. Lastly I think that while these are classifiable as covenants in implementation, they are closer in use to multisig pre-signed scripts, without the requirement of interactive setup. We should think of these as 'certified checks' instead, which can also describe a pre-signed design satisfactorily. With true covenants we don't want require the satisfying conditions to be 'computationally enumerable' (e.g. we can't in computational limits enumerate all public keys if the covenant expresses a spend must be to a public key). And if the covenant is computationally enumerable, then we should use this construct and put the spending paths into a Huffman encoded taproot tree. On Tue, May 21, 2019, 12:41 PM Matt Corallo wrote: > If we're going to do covenants (and I think we should), then I think we > need to have a flexible solution that provides more features than just > this, or we risk adding it only to go through all the effort again when > people ask for a better solution. > > Matt > > On 5/20/19 8:58 PM, Jeremy via bitcoin-dev wrote: > > Hello bitcoin-devs, > > > > Below is a link to a BIP Draft for a new opcode, > > OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless > > congestion control techniques via a rudimentary, limited form of > > covenant which does not bear the same technical and social risks of > > prior covenant designs. > > > > Congestion control allows Bitcoin users to confirm payments to many > > users in a single transaction without creating the UTXO on-chain until a > > later time. This therefore improves the throughput of confirmed > > payments, at the expense of latency on spendability and increased > > average block space utilization. The BIP covers this use case in detail, > > and a few other use cases lightly. > > > > The BIP draft is here: > > > https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki > > > > The BIP proposes to deploy the change simultaneously with Taproot as an > > OPSUCCESS, but it could be deployed separately if needed. > > > > An initial reference implementation of the consensus changes and tests > > which demonstrate how to use it for basic congestion control is > > available at > > https://github.com/JeremyRubin/bitcoin/tree/congestion-control. The > > changes are about 74 lines of code on top of sipa's Taproot reference > > implementation. > > > > Best regards, > > > > Jeremy Rubin > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
If we're going to do covenants (and I think we should), then I think we need to have a flexible solution that provides more features than just this, or we risk adding it only to go through all the effort again when people ask for a better solution. Matt On 5/20/19 8:58 PM, Jeremy via bitcoin-dev wrote: > Hello bitcoin-devs, > > Below is a link to a BIP Draft for a new opcode, > OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless > congestion control techniques via a rudimentary, limited form of > covenant which does not bear the same technical and social risks of > prior covenant designs. > > Congestion control allows Bitcoin users to confirm payments to many > users in a single transaction without creating the UTXO on-chain until a > later time. This therefore improves the throughput of confirmed > payments, at the expense of latency on spendability and increased > average block space utilization. The BIP covers this use case in detail, > and a few other use cases lightly. > > The BIP draft is here: > https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki > > The BIP proposes to deploy the change simultaneously with Taproot as an > OPSUCCESS, but it could be deployed separately if needed. > > An initial reference implementation of the consensus changes and tests > which demonstrate how to use it for basic congestion control is > available at > https://github.com/JeremyRubin/bitcoin/tree/congestion-control. The > changes are about 74 lines of code on top of sipa's Taproot reference > implementation. > > Best regards, > > Jeremy Rubin > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
