Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
On Sat., Feb. 4, 2023, 21:01 Peter Todd, wrote: > > > On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev > wrote: > >Since bytes in the witness are cheaper than bytes in the script pubkey, > >there is a crossover point in data size where it will simply be cheaper to > >use witness data. Where that crossover point is depends on the finer > >details of the overhead of the two methods, but you could make some > >reasonable assumptions. Such a calculation could form the basis of a > >reasonable OP_RETURN proposal. I don't know if it would be persuasive, > but > >it would at least be coherent. > > I don't think it's worth the technical complexity trying to carefully > argue a specific limit. Let users decide for themselves how they want to > use OpReturn. > Even better. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
Yes. If you would otherwise sign the tapleaf, then I would recommend also signing the entire tapbranch. On Sat, Feb 11, 2023 at 12:15 AM Anthony Towns wrote: > On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >The fix for the bug is to sign the entire tapbranch instead of the > tapleaf. > > > >On Wed., Feb. 8, 2023, 04:35 Michael Folkson, < > michaelfolk...@protonmail.com> > >wrote: > > > >> Hi Andrew > >> > >> > There is a bug in Taproot that allows the same Tapleaf to be repeated > >> multiple times in the same Taproot, potentially at different Taplevels > >> incurring different Tapfee rates. > >> > > >> > The countermeasure is that you should always know the entire Taptree > >> when interacting with someone's Tapspend. > >> > >> I wouldn't say it is a "bug" unless there is a remedy for the bug that > >> wasn't (and retrospectively should have been) included in the Taproot > >> design. In retrospect and assuming you could redesign the Taproot > consensus > >> rules again today would you prevent spending from a valid P2TR address > if a > >> repeated Tapleaf hash was used to prove that a spending path was > embedded > >> in a Taproot tree? That's the only thing I can think of to attempt to > >> remedy this "bug" and it would only be a partial protection as proving a > >> spending path exists within a Taproot tree only requires a subset of the > >> Tapleaf hashes. > >> > >> I only point this out because there seems to be a push to find "bugs" > and > >> "accidental blowups" in the Taproot design currently. No problem with > this > >> if there are any, they should definitely be highlighted and discussed if > >> they do exist. The nearest to a possible inferior design decision thus > far > >> that I'm aware of is x-only pubkeys in BIP340 [0]. > >> > >> Thanks > >> Michael > >> > >> [0]: > >> > https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340 > >> > >> -- > >> Michael Folkson > >> Email: michaelfolkson at protonmail.com > >> Keybase: michaelfolkson > >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > >> > >> --- Original Message --- > >> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via > bitcoin-dev < > >> bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > >> There is a bug in Taproot that allows the same Tapleaf to be repeated > >> multiple times in the same Taproot, potentially at different Taplevels > >> incurring different Tapfee rates. > >> > >> The countermeasure is that you should always know the entire Taptree > when > >> interacting with someone's Tapspend. > >> > >> > >> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev < > >> bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > >>> > >>> Some people highlighted some minor problems with my last email: > >>> > >>> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via > bitcoin-dev > >>> wrote: > >>> > > >>> > > >>> > > >>> > [1] https://bitcoin.sipa.be/miniscript/ > >>> > [2] In Taproot, if you want to prevent signatures migrating to > another > >>> > branch or within a branch, you can use the CODESEPARATOR opcode > >>> > which was redisegned in Taproot for exactly this purpose... we > >>> > really did about witness malleation in its design! > >>> > >>> In Taproot the tapleaf hash is always covered by the signature (though > >>> not in some ANYONECANPAY proposals) so you can never migrate signatures > >>> between tapbranches. > >>> > >>> I had thought this was the case, but then I re-confused myself by > >>> reading BIP 341 which has much of the sighash specified, but not > >>> all of it! The tapleaf hash is added in BIP 342. > >>> > >>> > > >>> > If you want to prevent signatures from moving around *within* a > >>> > branch, > >>> > > >>> > >>> And this sentence I just meant to delete :) > >>> > >>> > >>> -- > >>> Andrew Poelstra > >>> Director of Research, Blockstream > >>> Email: apoelstra at wpsoftware.net > >>> Web: https://www.wpsoftware.net/andrew > >>> > >>> The sun is always shining in space > >>> -Justin Lewis-Webster > >>> > >>> ___ > >>> bitcoin-dev mailing list > >>> bitcoin-dev@lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >>> > >> > >> > > Is this something that should be fixed in bip118 signatures then? > > Cheers, > aj > -- > Sent from my phone. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Since bytes in the witness are cheaper than bytes in the script pubkey, there is a crossover point in data size where it will simply be cheaper to use witness data. Where that crossover point is depends on the finer details of the overhead of the two methods, but you could make some reasonable assumptions. Such a calculation could form the basis of a reasonable OP_RETURN proposal. I don't know if it would be persuasive, but it would at least be coherent. On Sat., Feb. 4, 2023, 18:17 Aymeric Vitte via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > I don't know, what number would you advise? When I made the > bitcoin-transactions nodejs module some years ago the limit (from the > specs) was 512B > > It's not a fork, super easy to do > > And necessary because bitcoin on ground of I don't know what rule > allowing the IF/ENDIF "unlimited" storage just mimics ethereum for the > worse, and is again quite dubious to use > > > Le 04/02/2023 à 23:18, Christopher Allen a écrit : > > 520 because that is a similar limit in taproot? Some multiple of > > hash+signature+metadata to satisfy others (that still might not be > > satisfied by any choice). > > > ___ > 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] Unenforceable fee obligations in multiparty protocols with Taproot inputs
There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates. The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend. On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Some people highlighted some minor problems with my last email: > > On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev > wrote: > > > > > > > > [1] https://bitcoin.sipa.be/miniscript/ > > [2] In Taproot, if you want to prevent signatures migrating to another > > branch or within a branch, you can use the CODESEPARATOR opcode > > which was redisegned in Taproot for exactly this purpose... we > > really did about witness malleation in its design! > > In Taproot the tapleaf hash is always covered by the signature (though > not in some ANYONECANPAY proposals) so you can never migrate signatures > between tapbranches. > > I had thought this was the case, but then I re-confused myself by > reading BIP 341 which has much of the sighash specified, but not > all of it! The tapleaf hash is added in BIP 342. > > > > > If you want to prevent signatures from moving around *within* a > > branch, > > > > And this sentence I just meant to delete :) > > > -- > Andrew Poelstra > Director of Research, Blockstream > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > The sun is always shining in space > -Justin Lewis-Webster > > ___ > 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] Unenforceable fee obligations in multiparty protocols with Taproot inputs
The fix for the bug is to sign the entire tapbranch instead of the tapleaf. On Wed., Feb. 8, 2023, 04:35 Michael Folkson, wrote: > Hi Andrew > > > There is a bug in Taproot that allows the same Tapleaf to be repeated > multiple times in the same Taproot, potentially at different Taplevels > incurring different Tapfee rates. > > > > The countermeasure is that you should always know the entire Taptree > when interacting with someone's Tapspend. > > I wouldn't say it is a "bug" unless there is a remedy for the bug that > wasn't (and retrospectively should have been) included in the Taproot > design. In retrospect and assuming you could redesign the Taproot consensus > rules again today would you prevent spending from a valid P2TR address if a > repeated Tapleaf hash was used to prove that a spending path was embedded > in a Taproot tree? That's the only thing I can think of to attempt to > remedy this "bug" and it would only be a partial protection as proving a > spending path exists within a Taproot tree only requires a subset of the > Tapleaf hashes. > > I only point this out because there seems to be a push to find "bugs" and > "accidental blowups" in the Taproot design currently. No problem with this > if there are any, they should definitely be highlighted and discussed if > they do exist. The nearest to a possible inferior design decision thus far > that I'm aware of is x-only pubkeys in BIP340 [0]. > > Thanks > Michael > > [0]: > https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340 > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > --- Original Message --- > On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > There is a bug in Taproot that allows the same Tapleaf to be repeated > multiple times in the same Taproot, potentially at different Taplevels > incurring different Tapfee rates. > > The countermeasure is that you should always know the entire Taptree when > interacting with someone's Tapspend. > > > On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> Some people highlighted some minor problems with my last email: >> >> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev >> wrote: >> > >> > >> > >> > [1] https://bitcoin.sipa.be/miniscript/ >> > [2] In Taproot, if you want to prevent signatures migrating to another >> > branch or within a branch, you can use the CODESEPARATOR opcode >> > which was redisegned in Taproot for exactly this purpose... we >> > really did about witness malleation in its design! >> >> In Taproot the tapleaf hash is always covered by the signature (though >> not in some ANYONECANPAY proposals) so you can never migrate signatures >> between tapbranches. >> >> I had thought this was the case, but then I re-confused myself by >> reading BIP 341 which has much of the sighash specified, but not >> all of it! The tapleaf hash is added in BIP 342. >> >> > >> > If you want to prevent signatures from moving around *within* a >> > branch, >> > >> >> And this sentence I just meant to delete :) >> >> >> -- >> Andrew Poelstra >> Director of Research, Blockstream >> Email: apoelstra at wpsoftware.net >> Web: https://www.wpsoftware.net/andrew >> >> The sun is always shining in space >> -Justin Lewis-Webster >> >> ___ >> 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
