From: Anthony Towns <aj@erisian•com.au>
To: Russell O'Connor <roconnor@blockstream•io>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail•com>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Fri, 28 Jun 2019 19:49:37 +1000 [thread overview]
Message-ID: <20190628094937.u5zisdhdyfc6g5ts@erisian.com.au> (raw)
In-Reply-To: <CAMZUoKnniSEy4RM2DWCRxzVyYsGJ3Rbw4sbFv0zxuPi9gwoXYA@mail.gmail.com>
On Wed, Jun 26, 2019 at 08:08:01PM -0400, Russell O'Connor via bitcoin-dev wrote:
> I have a comment about the 'input_index' of the transaction digest for taproot
> signatures. It is currently listed as 2 bytes. I think it would be better to
> expand that to 4 bytes.
FWIW, I think this would be essentially free, at least for the current
sighash modes, as (I think) all the non-ANYONECANPAY modes have at least
4 bytes of sha256 padding at present.
In addition to (or, perhaps, as a special case of) the reasons Russell
gives, I think this change would also better support proof-of-reserves
via taproot signatures (cf [0] or BIP 127), as it would allow the proof
tx to include more than 65k utxos with each utxo being signed with a
signature that commits to all inputs including the invalid placeholder.
[0] https://blockstream.com/2019/02/04/en-standardizing-bitcoin-proof-of-reserves/
If you didn't have this, but wanted to do proof-of-reserves over >65k
taproot UTXOs, you could use ANYONECANPAY signatures, and use the output
amounts to ensure the signatures can't be abused, something like:
inputs:
0: spend from txid 0000..0000 vout 0, no witness data
1: utxo1, signed with ANYONECANPAY|ALL
2: utxo2, signed with ANYONECANPAY|ALL
3: utxo3, signed with ANYONECANPAY|ALL
[etc]
outputs:
0: sum(utxo1..utxoN), pay to self
1: 2099999997690001-sum(utxo1..utxo3), payable to whatever
The total output value is therefore one satoshi more bitcoin than there
could ever have been, so none of the utxoK signatures can be reused on the
blockchain (unless there's severe inflation due to bugs or hardforks),
but the values (and sums) all remain less than 21M BTC so it also won't
fail the current "amount too big" sanity checks.
That seems a bit more fragile/complicated than using SIGHASH_ALL for
everything, though it means your cold wallet doesn't have to serialize
your >65k transactions to verify it's signing what it thinks it is.
> [1]The var-integer field for the number of inputs (and the number of outputs)
> in a transaction looks like it should allow upto 2^64-1 inputs; however this is
> an illusion. The P2P rules dictate that these values are immediately taken
> modulo 2^32 after decoding. For example, if the number of inputs is a
> var-integer encoding of 0x0100000001, it is actually just a non-canonical way
> of encoding that there is 1 input. Try this at home!
Hmm? If I'm following what you mean, that's not the P2P rules, it's the
Unserialize code, in particular:
compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int assumed");
serialize.h:289:uint64_t ReadCompactSize(Stream& is)
serialize.h-679-template<typename Stream, unsigned int N, typename T, typename V>
serialize.h-680-void Unserialize_impl(Stream& is, prevector<N, T>& v, const V&)
serialize.h-681-{
serialize.h-682- v.clear();
serialize.h:683: unsigned int nSize = ReadCompactSize(is);
(and other Unserialize_impl implementations)
However, ReadCompactSize throws "size too large" if the return value is
greater than MAX_SIZE == 0x02000000 =~ 33.5M, which prior to the implicit
cast to 32 bits in Unserialize_impl. And it looks like that check's been
there since Satoshi...
So as far as I can see, that encoding's just unsupported/invalid, rather
than equivalent/non-canonical?
Cheers,
aj
next prev parent reply other threads:[~2019-06-28 9:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 17:57 Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr
2019-05-07 20:42 ` Sjors Provoost
2019-05-08 4:37 ` ZmnSCPxj
2019-05-08 5:16 ` ZmnSCPxj
2019-05-08 23:06 ` Pieter Wuille
2019-05-18 17:51 ` ZmnSCPxj
2019-05-08 3:44 ` ZmnSCPxj
2019-05-09 16:56 ` Johnson Lau
2019-05-10 5:38 ` ZmnSCPxj
2019-05-08 4:49 ` Anthony Towns
2019-05-08 13:10 ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23 2:06 ` Pieter Wuille
2019-05-23 2:32 ` Russell O'Connor
2019-05-22 14:14 ` John Newbery
2019-09-16 16:18 ` Greg Sanders
2019-09-17 4:09 ` ZmnSCPxj
2019-09-18 21:21 ` Pieter Wuille
2019-06-27 0:08 ` Russell O'Connor
2019-06-28 9:49 ` Anthony Towns [this message]
2019-06-28 11:16 ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190628094937.u5zisdhdyfc6g5ts@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
--cc=roconnor@blockstream$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox