Andrew Poelstra [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-06-06 to 2023-04-05
💬 Posted a total of 51 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1ae27kq6z802dkqw4ey4dgdx493szm8dpmcm76d7vt0ma9gf6fj4svz5t04

Profile Code

nprofile1qqswu40tqdprh4xmq82uj2k5xn2jccpdnksaudldxlx9ha7j5yaye2cprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hs45pqfq

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Author Public Key

npub1ae27kq6z802dkqw4ey4dgdx493szm8dpmcm76d7vt0ma9gf6fj4svz5t04

Show more details

Last Notes

2023-08-12 09:56:45 GMT

- reply

📅 Original date posted:2023-08-11
🗒️ Summary of this message: The author is seeking input on the function "is_segwit()" and its return value for p2tr transactions. The term "segwit v0" is used for p2wsh or p2wpkh outputs.
📝 Original message:
On Fri, Aug 11, 2023 at 02:45:57PM +1000, Tobin Harding via bitcoin-dev wrote:
> Question for OG bitcoin API designers please.
>
> If you were to see the following function
>
> `is_segwit()`
>
> would you assume it returns `true` or `false` for a p2tr transaction?
>
>
> Currently we (rust-bitcoin) are being liberal with the use of `v0` but
> its a pretty ugly. Is there an official, or widely used, name for segwit v0?
>
As others have said, I think `is_segwit` should match all segwit
versions. Pavol also sorta answered your "widely used name" question
though he didn't draw attention to it -- segwit v0 outputs are called
"p2wsh" or "p2wpkh".
But I don't know any term that covers "p2wsh or p2wpkh but not p2tr".
Other than "segwit_v0", which we are currently using, and which I agree
is a bit of a mouthful.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230811/edc59c34/attachment.sig>

2023-06-09 12:49:37 GMT

- reply

📅 Original date posted:2018-03-19
📝 Original message:
Hi ZmnSCPxj,
Yep, I'm pretty sure this works the way you describe -- essentially replace
the hash challenges with adaptor signatures which are reblinded at each layer.
Because adaptor signatures can make arbitrary sets of signatures atomic (and
don't require any precommitments in the blockchain) it's easy to do multipath
stuff this way. And using discrete logs as challenges makes reblinding and
transferrable proof-of-payment easy.
It's also true that you can use BIP32 hardened keys for the challenges. You
might as well use HMAC rather than a hash for the sake of standardness, but
I don't think there's any particular reason to do this for key derivation.
Then Taproot can hide the non-cooperative cases as you mention.
I've been working on understanding Lightning and figuring out best way to
use the full power of scriptless scripts. I think we can do better than just
dropping TR+SS into the existing architecture. (Some of AJ's recent emails
to the list have been one-sided commentary on ideas I floated to him in
person recently, but I haven't had time to get everything straight enough
in my mind to reply.)
For example, with adaptor signatures + Graftroot [1], one party can make their
commit-tx signature atomic with a delegation to a timelock script; the other
party does the same but for a different timelock script. Then maybe both parties
can share the same commit tx rather than doing the symmetric thing, which would
save space and simplify the protocol a bit. And more generally, this "output
has different spend conditions depending on who publishes to the chain" primitive
seems like a really powerful thing, and AFAIK nobody has noticed this feature of
Graftroot until very recently.
Cheers
Andrew
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
On Sun, Mar 18, 2018 at 08:25:13PM -0400, ZmnSCPxj via Lightning-dev wrote:
> Good morning list,
>
> I sketch here the idea, of making atomic multipath payment (AMP), with the properties:
>
> 1. Has a proof-of-payment.
> 2. Multipath decorrelation.
>
> Note: I am not a mathematician. Thus, it is likely, that there is a mistake here, and we cannot make this work.
>
> First, we look at BIP32 hierarchically derived (HD) keys by Wuille. Roughly, given a parent private key k_par, we can do derive k_i child keys for integer i by:
>
> k_i = H(i || k_par * G) + k_par
>
> where H(x) is a hash function and G is the generator point. (this it not quite how BIP32 does it, it uses HMAC, maybe that is safer for some reason that my non-mathematician self is unaware of...)
>
> The parent public key K_par = k_par * G. We can derive K_i public child keys for integer i by:
>
> K_i = H(i || K_par) * G + K_par
>
> (I think)
>
> Note that K_i = k_i * G still, as is usual for elliptic curve asymmetric cryptography:
>
> K_i = k_i * G = (H(i || k_par * G) + k_par) * G = H(i || k_par * G) * G + k_par * G = H(i || K_par) * G + K_par
>
> Of note is that if we know an i, a private child key k_i corresponding to that i, and the public parent key K_par, we can derive the private parent key k_par:
>
> k_i = H(i || K_par) + k_par
>
> k_par = k_i - H(i || K_par)
>
> Now all we need is to have a conditional payment, which can only be performed if the payee provides a private key which matches a public key, i.e. given x * G, the payee must provide x.
>
> Fortunately Poelstra has done this work beforehand in the Scriptless Script (SS) concept, where the payee provides a T = t * G, and the Scriptless Script construction requires that the payee reveal the t in order to claim the payment. I will not go into the math since there is a good chance I shall make a mistake; look up discussions by better mathematicians by me. Scriptless Script requires Bellare-Neven (BN) signatures to work.
>
> Note that Scriptless Script handles only the equivalent of hashlocking. We still need a timelock in case the payee refuses to reveal the proof-of-payment t.
>
> Fortunately, Maxwell has provided a construction, taproot (TR). This construction has two top-level branches: a Bellare-Neven n-of-n, or a Bitcoin Script. We know that Scriptless Script can make an equivalent to a hashlock from a Bellare-Neven n-of-n. The other branch of a taproot construction can now be a simple OP_CLTV+OP_CHECKSIG script, forming the timelock half of an HTLC.
>
> How would a multipath payment work? The invoice would contain the parent public key K_par. From this, the payer derives as many K_i, as it needs to split the payment to. It sets up conditional payments that require revelation of the private child key k_i for each K_i it derives.
>
> When the payee receives a partial payment, it is not incentivized to claim it immediately yet. This is because revelation of even one child key k_i will, in combination with the parent public key K_par, reveal the parent private key k_par, which serves as proof-of-payment. The payee will wait for the entire payment to reach it, and then claim all of them. This reveals all the private child keys k_i, any one of which will let the payer extract the parent private key k_par that serves as proof-of-payment.
>
> Each path has a different k_i, thus providing multipath decorrelation.
>
> (Please check my math --- I am not a mathematician and it is possible I have made a mistake somewhere)
>
> Regards,
> ZmnSCPXj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180319/b2f89db2/attachment-0001.sig>

2023-06-07 23:19:48 GMT

- reply

📅 Original date posted:2023-02-20
🗒️ Summary of this message: Andrew Poelstra has opened a PR to the BIPs repo for a new scheme, with updates to address concerns raised by Pavol Rusnak, David Harding, and Christopher Allen.
📝 Original message:On Wed, Feb 15, 2023 at 09:16:02PM -0500, Russell O'Connor via bitcoin-dev wrote:
> I've been asked by Dr. Curr and Professor Snead to forward this message to
> this mailing list, as it may be of general interest to Bitcoin users.
>
> <snip>
>
I have opened a PR to the BIPs repo for this scheme: https://github.com/bitcoin/bips/pull/1425
Thanks very much to Pavol Rusnak, David Harding, and Christopher Allen
for their comments on this list. We've updated the draft text to try to
address your concerns. In particular:
* Added more text to "Motivation" distinguishing the scheme from SLIP-39
* Added more details to "Rationale" about error correction capabilities
of the code, and to explain that the code does not defend against
malicious errors
* Added a note to use uppercase for QR codes
* Rearranged and clarified the "creating shares" instructions
* Added text about hand-computation, in particular hand-computation
of share verification, to "Motivation".
If any of you would like to be listed under Acknowledgements, please let
me know here or on the PR.
Cheers
Andrew
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230220/38465703/attachment.sig>

2023-06-07 23:19:36 GMT

- reply

📅 Original date posted:2023-02-17
🗒️ Summary of this message: Andrew Poelstra suggests using static analysis to ensure inscription scripts are "plausible" and comply with the CLEANSTACK rule, which could increase their space cost.
📝 Original message:On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote:
> On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
> >You could try statically analyze `<anything>` to determine whether the
> >IF branch could ever be taken. For example there is no path through
> >the "inscription script" that would result in all the crap being dropped
> >by the end of the script, violating the CLEANSTACK rule.
> >
> >This sort of filtering, assuming it could be reliably and efficiently
> >done, would at least force inscription scripts to be "plausible", and
> >would greatly increase their space cost by e.g. requiring OP_DROP to be
> >added somewhere hundreds of times.
>
> "greatly increase their space cost"?
>
> Tell me, what is the actual % increase to adding OP_DROPs like you propose?
>
By standardness rules (where you can have up to 80-byte pushes), a
little over 1%. By consensus (520-byte pushes) less than 0.2%.
Perhaps "greatly increase" is a stretch :) but if the fee market is
functioning and we're talking about large amounts of data, it's not
trivial either.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230218/dcd75895/attachment.sig>

2023-06-07 23:19:34 GMT

- reply

📅 Original date posted:2023-02-17
🗒️ Summary of this message: Andrew Poelstra suggests filtering script fragments to make inscription scripts "plausible" and increase their space cost, but warns against banning legitimate use cases.
📝 Original message:On Fri, Feb 17, 2023 at 03:56:31PM +0100, vjudeu via bitcoin-dev wrote:
> > [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
>
> I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. Because "OP_FALSE OP_IF <anything> OP_ENDIF" is effectively the same as "OP_NOP", and putting NOPs in many places is considered non-standard. The same is true for "OP_TRUE OP_NOTIF <anything> OP_ENDIF", and also there are many variants, where someone could use "OP_FALSE OP_NOT" instead of "OP_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" (instead of putting "OP_TRUE").
>
If you ban any of these specific script fragments then spammers will
just use `IF <anything> ENDIF` and provide the `FALSE` as a zero push.
And banning *this* would ban legitimate use cases.
You could try statically analyze `<anything>` to determine whether the
IF branch could ever be taken. For example there is no path through
the "inscription script" that would result in all the crap being dropped
by the end of the script, violating the CLEANSTACK rule.
This sort of filtering, assuming it could be reliably and efficiently
done, would at least force inscription scripts to be "plausible", and
would greatly increase their space cost by e.g. requiring OP_DROP to be
added somewhere hundreds of times.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230217/c02a60b1/attachment-0001.sig>

2023-06-07 23:19:04 GMT

- reply

📅 Original date posted:2023-02-05
🗒️ Summary of this message: A proposal has been made to make OP_RETURN a free-for-all, given that users have found ways to store arbitrary amounts of data on-chain.
📝 Original message:On Sat, Feb 04, 2023 at 07:11:35PM -0500, 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 agree with Peter that, given that users have found ways to store arbitrary
amounts of data on-chain if they really want, we might as well just make
OP_RETURN a free-for-all.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230205/210aac82/attachment.sig>

2023-06-07 23:18:55 GMT

- reply

📅 Original date posted:2023-02-01
🗒️ Summary of this message: A technical discussion on the efficiency of using OP_FALSE IF ... ENDIF versus OpPush <data> OpDrop for pushing large amounts of data into the Bitcoin blockchain.
📝 Original message:On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
>
>
> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >All other things being equal, which is better if you need to place a
> >64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
> >taproot transaction such as:
> >
> >OP_FALSE
> >OP_IF
> >OP_PUSH my64bytes
> >OP_ENDIF
>
> What's wrong with OpPush <data> OpDrop?
>
This is a technical nit, but the reason is that <data> is limited to 520
bytes (and I believe, 80 bytes by standardness in Taproot), so if you
are pushing a ton of data and need multiple pushes, it's more efficient
to use FALSE IF ... ENDIF since you avoid the repeated DROPs.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230201/4ed63515/attachment.sig>

2023-06-07 23:14:05 GMT

- reply

📅 Original date posted:2022-10-18
📝 Original message:On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote:
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
No, as I understand the proposal, the "public key" held by the wallet is simply
a signing key used to authenticate addresses, and never leaves the wallet. Yes,
if the wallet's own memory is compromised, it can be tricked into accepting bad
addresses, but this is much much harder than compromising data on the clipboard,
which basically any application can do without any "real" exploits or special
permissions.
As an extreme, this proposal could be run on a hardware wallet which had some
out-of-band way to obtain and authenticate public keys (similar to Signal QR
codes).
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/4b4311f4/attachment.sig>

2023-06-07 23:13:58 GMT

- reply

📅 Original date posted:2022-09-29
📝 Original message:I'm really happy to see this discussion. I don't have any comments on the spec
because I think I'd have to be more in-the-weeds trying to implement a hww to
understand how well it works for realistic use cases. But a strong concept-ACk
from me and thanks to Salvatore for exploring this!
On Mon, May 09, 2022 at 11:36:47AM +0000, darosior via bitcoin-dev wrote:
>
> Unrelated question, since you mentioned `musig2` descriptors in this context. I thought Musig2 wasn't really
> feasible for hardware signing devices, especially stateless ones. Do you think/know whether it is actually
> possible for a HW to take part in a Musig2?
>
As Salvatore mentioned in his reply, there are a couple ways that hwws can deal
with musig2 -- specifically, having state (and I believe you can get away with
as little state as a single monotonic counter) or having a RNG which is reliable
enough that it at least won't repeat values.
Because these aren't blockers for all hwws, even if they are blockers for some,
I'd really like to see musig2 support in these protocols, or at least for musig2
to be considered in their design.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220929/b9bc0273/attachment.sig>

2023-06-07 23:10:42 GMT

- reply

📅 Original date posted:2022-06-14
📝 Original message:On Tue, Jun 14, 2022 at 01:15:08PM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> I'm replying to Peter, skipping the other emails.
>
> I perceive all these emails as disruptive trolling, ignoring the
> importance of real timestamping, while handwaving about things that
> are roughly false and harmful.
>
> Since the start of cryptocurrency, Bitcoin has been used to write
> timestamps that stay intact despite malicious action to arbitrary
> systems and records, showing the earliest on-chain publication of
> data. It seems misleading that OTS does not do that, when it is such a
> prominent system.
>
Please be cautious with tone and when assuming bad faith. I don't believe
that Peter is trolling. Also, as politely as I can, when something like
OTS whose model is dead-simple, well-documented, and has been running for
years providing significant value to many people, comes under attack for
being underspecified or failing to do what it says ... this is a
surprising claim, to say the least.
After talking to a few people offline, all of whom are baffled at this
entire conversation, I think the issue might come down to the way that
people interpret "timestamping".
If you believe that "timestamping" means providing a verifiable ordering
to events, then of course OTS does not accomplish this, nor has it ever
claimed to. If you think that "timestamping" means proving that some
data existed at a particular time, then this is exactly what OTS does.
Personally -- and I suspect this is true of Peter as well -- I have always
read the word as having the latter meaning, and it never occurred to me
until now that others might have a different interpretation.
I apologize for contributing to a thread that is getting a bit out of hand,
but I hope this can help the different parties see where the confusion is.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/023b2f8a/attachment.sig>

2023-06-07 22:51:43 GMT

- reply

📅 Original date posted:2021-04-16
📝 Original message:On Fri, Apr 16, 2021 at 03:34:33PM +0000, Christopher Gilliard via bitcoin-dev wrote:
> This sounds like a good justification to remove the legacy multi-signature
> capabilities as well.
>
Doing so would confiscate coins, and also it is impossible to remove
legacy multisignatures in general without gutting almost all of Script.
> >> Thus, given that it is otherwise impossible to stop people from putting
> arbitrary data values into their transactions, then we rather encourage
> people who are going to encode their arbitrary data in transaction to use
> the OP_RETURN outputs in order to avoid UTXO bloat.
>
> You can't make it completely impossible to do that, but you can make it
> harder and at the same time you can provide a solution for doing what they
> want to do.
>
I don't think you can even make it harder in a meaningful sense. There is
too much flexibility in transaction data.
--
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

2023-06-07 18:30:57 GMT

- reply

📅 Original date posted:2021-03-16
📝 Original message:On Tue, Mar 16, 2021 at 03:10:21PM +0100, Andrea via bitcoin-dev wrote:
>
> Hi! Sorry for the OT, could you provide some references to ring signatures
> over/for/via taproot (I mean the schema or something like that)? And what is
> "Provisions" (the capital letter makes me think it's a product/technology)?
> I'm a rookie following this mailing since just a few months...
>
Thanks for posting such a positive message in an otherwise tense thread :)
Provisions is a scheme for providing proof of ownership of funds, developed
by Dagher et al in 2015 at https://eprint.iacr.org/2015/1008 . The way it
works is to collect all of the Bitcoin outputs which have exposed/known
public keys then associate to these keys a Pedersen commitment which commits
to the outputs' amounts in a homomorphic way.
Homomorphic means that even though the commitments hide what the original
amounts are, anyone can add them together (in some sense) to get a new
commitment to the sum of the original amounts.
So Provisions is essentially a zero-knowledge proof of the following statement
1. I have a commitment to >100BTC (or whatever)...
2. ...which is a sum of commitments of actual UTXO values...
3. ...where these UTXOs come from the set of known-public-key UTXOs...
4. ...and I am able to sign with the public keys associated to them.
which proves ownership of some amount of BTC, without revealing which specific
UTXOs were involved. This zero-knowledge proof can be done fairly efficiently
by exploiting the structure of EC public keys and Pedersen commitments.
Unfortunately, most unspent Bitcoin outputs do not have known public keys,
which means that you can only do a Provisions proof using a small anonymity
set. However, all Taproot outputs, by virtue of having exposed public keys
(which is the point under contention in this thread), will be in the set of
exposed-public-key UTXOs, allowing people to do Provisions proofs where
their anonymity set consists of a large proportion of active coins.
BTW, even without Provisions, there are some similar and simpler things you
can do with Taproot keys along these lines. See for example
https://twitter.com/n1ckler/status/1334240709814136833
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210316/a17a0bd9/attachment-0001.sig>

2023-06-07 18:30:54 GMT

- reply

📅 Original date posted:2021-03-16
📝 Original message:On Tue, Mar 16, 2021 at 03:44:25AM +0000, Luke Dashjr wrote:
> (To reiterate: I do not intend any of this as a NACK of Taproot.)
>
Thanks, although it's still somewhat frustrating to be rehashing this
discussion again after so many years.
> On Monday 15 March 2021 23:12:18 Andrew Poelstra wrote:
> > "No gain" except to save significant CPU time and bandwidth?
>
> The CPU time is localised to involved nodes, and (correct me if I'm wrong)
> trivial in comparison to what is required to run a full node in the first
> place. I'm not sure how it looks with bandwidth.
>
I really can't parse what "localized to involved nodes" means. All Bitcoin
nodes will be affected. Right now for nodes with sufficient bandwidth, signature
validation is the slowest part of validating transactions, which is why it
is disabled for the bulk of the chain during IBD. Taproot, by virtue of
enabling batch verification, would give a 2-3x speedup when validating the
same number of signatures.
> > Having exposed keys also lets you do ring signatures over outputs, creating
> > the ability to do private proof of funds via Provisions.
>
> But you can also do comparable proofs behind a hash with Bulletproofs, right?
>
Yes, if you are willing to accept independent >100000x slowdowns on proving,
verification and code review.
> > > Despite this, I still don't think it's a reason to NACK Taproot: it
> > > should be fairly trivial to add a hash on top in an additional softfork
> > > and fix this.
> >
> > This would make Bitcoin strictly worse.
>
> How so? People could just not use it if they don't care, right?
> The alternative (if people care enough) is that those concerned about quantum
> risk would be forced to forego the benefits of Taproot and stick to p2pkh or
> such, which seems like an artificial punishment.
>
People who do use it will reduce their privacy set, reduce the privacy set of
people who aren't using it, create confusion and delays for people implementing
Taproot, and slow down Bitcoin nodes who would have to validate the extra
material.
> > > In addition to the points made by Mark, I also want to add two more, in
> > > response to Pieter's "you can't claim much security if 37% of the supply
> > > is at risk" argument. This argument is based in part on the fact that
> > > many people reuse Bitcoin invoice addresses.
> >
> > 37% is a dramatic understatement. Every address which is derived using
> > BIP32 should be assumed compromised to a QC attacker because xpubs are not
> > treated like secret key material and are trivial to e.g. extract from
> > hardware wallets or PSBTs. I expect the real number is close to 100%.
>
> xpubs should be treated like secret key material IMO.
>
Your opinion is noted. This is not how xpubs are, in reality, treated. And
it would make them significantly less useful if you could no longer share
descriptors with people you would like to do multiparty transactions with.
> A quantum attacker would need to compromise your PC to attack a hardware
> wallet, right?
>
No, I expect you could get xpubs out of hardware wallets using any of the
web endpoints provided by hardware wallet vendors, or by asking it to update
a PSBT with any of its scriptpubkeys.
> > In any case, Taproot keys, when used according to the recommendation in
> > BIP-0341, are already hashes of their internal keys, so (a) Taproot outputs
> > actually have better quantum resistance than legacy outputs; and (b) adding
> > another hash would be strictly redundant.
>
> It not only stops the attacker from obtaining the original key, but also
> prevents creating a new private key that can spend the output?
>
I don't know what you mean by this. If the original key is usable, i.e. a QC
has appeared overnight, then Bitcoin is screwed. (For that matter, the same is
true if there is an overnight break in SHA2, or ECDSA, or any other major
component of Bitcoin. Fortunately this is not how cryptographic breaks have
historically appeared.) There is no new private key that could be created.
If there is a QC where we have some warning, then we need to disable all EC
operations in Script, including keypath spends of Taproot outputs, and this
would be true with or without the redundant extra hash.
Taproot, with or without the redundant hash, has a few distinct benefits over
legacy outputs in this scenario:
* Taproot keys are hashes of semi-secret data (at least as secret as xpubs)
in a well-defined and simple way, by virtue of committing to an internal
key and some script (usually unspendable)
* By adding secret data to the script, users can provide extra data to prove
in a QC-hard way, even if their internal key is compromised
* Taproot keys can be chosen to be provably unspendable except by a DL break,
as David Harding points out, by using a NUMS point as an internal key.
None of these factors are improved by adding an extra hash.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210316/75447235/attachment.sig>

2023-06-07 18:27:52 GMT

- reply

📅 Original date posted:2020-12-21
📝 Original message:On Tue, Dec 22, 2020 at 12:22:37AM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> Re-reading your proposed text, I'm wondering if the "consensus-only validation" extension is intended to replace the inconclusive-due-to-consensus-and-standardness-differ state. If so, I don't think it does, and regardless it doesn't seem very useful.
>
> What I'm suggestion could be specified this way:
> * If validator understands the script:
> * If signature is consensus valid (as far as the validator knows):
> * If signature is not known to trigger standardness rules intended for future extension (well-defined set of rules listed in BIP, and revisable): return valid
> * Otherwise: return inconclusive
> * Otherwise: return invalid
> * Otherwise: return inconclusive
>
> Or in other words: every signature has a well-defined result (valid, invalid, inconclusive) + validators may choose to report inconclusive for anything they don't understand.
>
> This has the property that as long as new consensus rules only change things that were covered under for-future-extension standardness rules, no two validators will ever claim valid and invalid for the same signature. Only valid+inconclusive or invalid+inconclusive.
>
I like it!
My thinking regarding standardness vs consensus rules was essentially that
I wanted to enforce the included standardness rules for anti-malleability
reasons, i.e. the hope that for "normal scripts" we would get strong signatures,
which may be important for anti-DoS reasons. (What I mean by this is that
if you can easily create mutations of signatures, it may confuse software
in similar ways to the Gox-era malleability attacks on wallet software of
the time.) But conversely, it is hard to enforce these rules as an
implementor, because libbitcoinconsensus does not expose them. So allowing
both forms of validation, to me, was an attempt to encourage adoption
rather than anything principled.
I didn't even consider the idea that validators should be able to signal "this
signature appears to use future consensus rules", although I should have been
clued in by your "upgradeable rules" language that this was your goal. Now that
you say this, it's obvious that this is desireable, and also obvious that using
the "inconclusive" state is an elegant way to achieve this.
I also agree that "confirming validators should never disagree on valid vs
invalid" is a good design goal and we should make that explicit.
I'll add a commit to my PR at https://github.com/bitcoin/bips/pull/1048 which
adds these thoughts.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201222/0486ba26/attachment.sig>

2023-06-07 18:27:50 GMT

- reply

📅 Original date posted:2020-12-18
📝 Original message:I have gone over BIP-0322 and substantially rewritten the text.
Everything I did is (I think) simply clarifying the existing
protocol, which felt like it was written by committee and wasn't
easy to follow, EXCEPT:
1. I rewrote the motivation section, which I believe originally
was a paraphrase of Luke-jr's general objections to having any
signmessage functionality. I hope Luke in particular can take
a look at what I wrote under "Motivation" and see if it
captures his concerns.
2. I merged the "consensus" and "upgradeable" rules to simply be
one set of rules, consisting of consensus checks plus additional
restrictions, all of which must be included. The new "Extensions"
section allows validators to output the state "consensus-valid"
if they really don't want to check the additional restrictions.
3. The "inconclusive" state, which was originally used for what I've
called "consensus-valid", now indicates that a validator does not
understand the script that it is checking (also described in the
new "Extensions" section). The goal is that implementors are able
to be meaningfully BIP-0322 while only supporting a subset of
Script, e.g. the templates that their own software supports, or
Miniscript, or the non-raw non-address set of output descriptors,
or whatever.
We have seen opposition to supporting BIP-322, e.g. [1] because
of the requirement that you either have a full script interpreter
(plus an open-ended list of Core's standardness flags, which is
not even available through libbitcoinconsensus) or nothing. On
the other hand, the vast majority of outputs are single-key p2pkh,
p2pkwh or p2sh-wpkh.
The new text is here (and for posterity I will also include it
inline below, though unless Github deletes it it will be easier
to read in rendered form):
https://github.com/apoelstra/bips/blob/2020-12--bip322-overhaul/bip-0322.mediawiki
I'll also PR this to the BIPs repo in the next day or two, and
comments on Github are then welcome.
[1] https://bitcointalk.org/index.php?topic=5261605.0
* * * * * Full text of the above link * * * * *
<pre>
BIP: 322
Layer: Applications
Title: Generic Signed Message Format
Author: Karl-Johan Alm <karljohan-alm at garage.co.jp>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322
Status: Draft
Type: Standards Track
Created: 2018-09-10
License: CC0-1.0
</pre>
== Abstract ==
A standard for interoperable signed messages based on the Bitcoin Script format, either for proving fund availability, or committing to a message as the intended recipient of funds sent to the invoice address.
== Motivation ==
The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network).
Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations.
== Types of Signatures ==
This BIP specifies three formats for signing messages: ''legacy'', ''simple'' and ''full''. Additionally, a variant of the ''full'' format can be used to demonstrate control over a set of UTXOs.
=== Legacy ===
New proofs should use the new format for all invoice address formats, including P2PKH.
The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format.
=== Simple ===
A ''simple'' signature consists of a witness stack, consensus encoded as a vector of vectors of bytes, and base64-encoded. Validators should construct <code>to_spend</code> and <code>to_sign</code> as defined below, with default values for all fields except that
* <code>message_hash</code> is a BIP340-tagged hash of the message, as specified below
* <code>message_challenge</code> in <code>to_spend</code> is set to the scriptPubKey being signed with
* <code>message_signature</code> in <code>to_sign</code> is set to the provided simple signature.
and then proceed as they would for a full signature.
=== Full ===
Full signatures follow an analogous specification to the BIP-325 challenges and solutions used by Signet.
Let there be two virtual transactions to_spend and to_sign.
The "to_spend" transaction is:
nVersion = 0
nLockTime = 0
vin[0].prevout.hash = 0000...000
vin[0].prevout.n = 0xFFFFFFFF
vin[0].nSequence = 0
vin[0].scriptSig = OP_0 PUSH32[ message_hash ]
vin[0].scriptWitness = []
vout[0].nValue = 0
vout[0].scriptPubKey = message_challenge
where <code>message_hash</code> is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = <code>BIP0322-signed-message</code>, and <code>message_challenge</code> is the to be proven (public) key script.
The "to_sign" transaction is:
nVersion = 0 or as appropriate (e.g. 2, for time locks)
nLockTime = 0 or as appropriate (for time locks)
vin[0].prevout.hash = to_spend.txid
vin[0].prevout.n = 0
vin[0].nSequence = 0 or as appropriate (for time locks)
vin[0].scriptWitness = message_signature
vout[0].nValue = 0
vout[0].scriptPubKey = OP_RETURN
A full signature consists of the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation.
=== Full (Proof of Funds) ===
A signer may construct a proof of funds, demonstrating control of a set of UTXOs, by constructing a full signature as above, with the following modifications.
* <code>message_challenge</code> is unused and shall be set to <code>OP_TRUE</code>
* Similarly, <code>message_signature</code> is then empty.
* All outputs that the signer wishes to demonstrate control of are included as additional outputs to <code>to_sign</code>, and their witness and scriptSig data should be set as though these outputs were actually being spent.
Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys.
== Detailed Specification ==
For all signature types, except legacy, the <code>to_spend</code> and <code>to_sign</code> transactions must be valid transactions which pass all consensus checks, except of course that the output with prevout <code>000...000:FFFFFFFF</code> does not exist.
We additionally require the following restrictions be met.
* All signatures must use the SIGHASH_ALL flag.
* The use of <code>CODESEPARATOR</code> or <code>FindAndDelete</code> is forbidden.
* The use of NOPs reserved for upgrades is forbidden.
* The use of segwit versions greater than 1 are forbidden.
* <code>LOW_S</code>, <code>STRICTENC</code> and <code>NULLFAIL</code>: valid ECDSA signatures must be strictly DER-encoded and have a low-S value; invalid ECDSA signature must be the empty push
* <code>MINIMALDATA</code>: all pushes must be minimally encoded
* <code>CLEANSTACK</code>: require that only a single stack element remains after evaluation
* <code>MINIMALIF</code>: the argument of <code>IF</code>/<code>NOTIF</code> must be exactly 0x01 or empty push
Future versions of this BIP may relax these rules, in particular those around NOPs and future Segwit versions, as they are deployed on Bitcoin.
=== Verification ===
Validation consists of the following steps. A validator is given as input an address ''A'' (which may be omitted in a proof-of-funds), signature ''s'' and message ''m'', and outputs one of four states (although validators are only required to be able to output the first and last):
* ''valid'' indicates that the signature passed all checks described below
* ''valid at time t and age s'' indicates that the signature has set timelocks but is otherwise valid (see "Extensions" below)
* ''consensus-valid'' indicates that the signature passed validation except for the additonal restrictions in the above section (see "Extensions" below)
* ''inconclusive'' means the validator was unable to check the scripts (see "Extensions" below)
* ''invalid'' means none of the other states
# Decode ''s'' as the transactions <code>to_sign</code> and <code>to_spend</code>
# Confirm that <code>message_hash</code> is the correct hash of ''m''
# Confirm that <code>message_challenge</code> is the scriptPubKey corresponding to ''A'' if ''A'' is present, and otherwise must be <code>OP_TRUE</code>
# Confirm that all other fields are set as specified above; in particular that
** <code>to_spend</code> has exactly one input and one output
** <code>to_sign</code> has at least one input and its first input spends the output of </code>to_spend</code>
** <code>to_sign</code> has exactly one output, as specified above
# Confirm that the two transactions together satisfy all consensus rules, except for <code>to_spend</code>'s missing input, and except that ''nSequence'' of <code>to_sign</code>'s first input and ''nLockTime'' of <code>to_sign</code> are not checked.
# Confirm that all of the above restrictions are met.
If the above conditions are met, the signature is considered ''valid''. Otherwise the signature is ''invalid''.
=== Signing ===
Signers who control an address ''A'' who wish to sign a message ''m'' act as follows:
# They construct <code>to_spend</code> and <code>to_sign</code> as specified above, using the scriptPubKey of ''A'' for <code>message_challenge</code> and tagged hash of ''m'' as <code>message_hash</code>.
# Optionally, they may set nLockTime of <code>to_sign</code> or nSequence of its first input.
# Optionally, they may add any additional outputs to <code>to_sign</code> that they wish to prove control of.
# They satisfy <code>to_sign</code> as they would any other transaction.
They then encode their signature, choosing either ''simple'' or ''full'' as follows:
* If they added no inputs to <code>to_sign</code>, left nSequence and nLockTime at 0, and ''A'' is a Segwit address (either pure or P2SH-wrapped), then they may base64-encode <code>message_signature</code>
* Otherwise they must base64-encode the concatenation of <code>to_spend</code> followed by <code>to_sign</code>.
== Extensions ==
To ease implementation, we allow some additional states to be output rather than ''valid'' or ''invalid''. Users who do not understand or who do not wish to deal with these states may treat them as ''invalid''.
=== Timelocks ===
If the nLockTime of <code>to_sign</code> is set to ''t'', and the nSequence of the first input of <code>to_sign</code> is set to ''s'', the validator may output the state ''valid at time t and age s''.
If both ''t'' and ''s'' are 0, the validator must instead output ''valid''.
Users may then wish to interpret this state as ''valid'' or ''invalid'' relative to the state of the current blockchain, but the rules for doing so are out of scope of this BIP.
=== Incomplete Validation ===
Some validators may not wish to implement a full script interpreter, choosing instead to support only specific script templates, or only Miniscript, for example. In this case, if they are unable to execute the scripts used by <code>to_sign</code>, they should output the state ''inconclusive''.
Users should interpret this state as the same thing as ''invalid'', although take it as a sign that they should find more capable software.
=== Consensus-Only Validation ===
Validators which are only able to check consensus-correctness of witnesses, but not the additional restrictions imposed by this BIP, may output the state ''consensus-valid'' to indicate that a signature has passed all consensus and structural checks.
Users should interpret this state as the same thing as ''valid'' but be aware that other software may fail to validate the same signature.
== Compatibility ==
This specification is backwards compatible with the legacy signmessage/verifymessage specification through the special case as described above.
== Reference implementation ==
TODO
== Acknowledgements ==
Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, and many others for their feedback on the specification.
== References ==
# Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html
== Copyright ==
This document is licensed under the Creative Commons CC0 1.0 Universal license.
== Test vectors ==
TODO
* * * * * End full text * * * * *
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201218/f7228b77/attachment.sig>

2023-06-07 18:27:46 GMT

- reply

📅 Original date posted:2020-12-23
📝 Original message:On Wed, Dec 23, 2020 at 12:30:20AM -0300, fiatjaf via bitcoin-dev wrote:
> Hi Andrew.
>
> I'm just a lurker here and I have not much experience with PSBTs, but still let me pose this very obvious question and concern: isn't this change going to create a compatibility nightmare, with some software supporting version 1, others supporting version 2, and the ones that care enough about UX and are still maintained being forced to support both versions -- and for no very important reason except some improvements in the way data is structured?
>
Yes, software will have to support both versions for a long time (likely
forever, at least in the case of Core). But I think this is okay, for a
couple of reasons:
1. it is very easy to convert from the old to new format, and from new to
old (unless the new one uses features unsupported by the old). Indeed,
the conversion logic is essentially the same as the logic that the
Extractor role uses, so there isn't even that much redundant code.
2. There actually isn't a lot of software using PSBT out there, and most
of that that does use PSBT is under rapid development. The obvious
exception to this deployed hardware wallets, but as far as "software
developers supporting old things for the sake of old hardware wallets"
I think this transition is an order of magnitude simpler to handle
than many of the ad-hoc protocol changes that individual vendors have
done. In other words this is a "fact of life", and not even one of
the grosser ones.
3. PSBT is pretty-much a dumb pure data format, and the diff between the
new format and the old is pretty small.
> Ultimately I don't think it should matter if some data is structured in not-the-best-possible way, as long as it is clear enough for the computer and for the libraries already written to deal with it. Backwards-compatibility and general interoperability is worth much more than anything else in these cases.
>
The reasons for switching to PSBT 2 are actually more than just structuring
the data in a cleaner way. I agree that if the point of this upgrade were
just elegance, it would not be worth the compatibility loss. But there are
practical limitations that this proposal eliminates:
1. PSBT provides no way to modify the set of inputs or outputs after the
Creator role is done.
2. Because of this, it forces certain things (e.g. locktimes and sequence
numbers) to be chosen by the Creator, who may not have all the relevant
information, and who certainly might not have it before any Updaters
have done their part.
as well, of course, as elegance reasons:
3. Parsers of the existing PSBT need to understand the Bitcoin transaction
format just to learn e.g. how many inputs and outputs there are. It is
impossible to parse a PSBT without also parsing (almost) the whole
transaction.
4. Similarly to cross-check fields like 'non_witness_utxo' which are
committed to in the transaction, you have to parse the whole transaction
just to make sure that the purely-redundant data is correctly redundant.
5. If you put a 0-input transaction into a PSBT (which would be pointless
because there's no way to add inputs, but it's not forbidden so your
software still has to deal with this somehow..), you need a different
transaction parser than the normal one, because there is an ambiguity
related to segwit that PSBT resolves differently.
It's also worth considering that PSBT is a young protocol, and future
extensions will be easier starting from PSBT 2 than starting from the
original version.
> Also let me leave this article here, which I find very important (even if for some reason it ends up not being relevant to this specific case): http://scripting.com/2017/05/09/rulesForStandardsmakers.html
>
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201223/05050b70/attachment.sig>

2023-06-07 18:27:44 GMT

- reply

📅 Original date posted:2020-12-16
📝 Original message:On Wed, Dec 09, 2020 at 10:25:37PM +0000, Andrew Chow via bitcoin-dev wrote:
> Hi All,
>
> I would like to propose a new PSBT version that addresses a few
> deficiencies in the current PSBT v0. As this will be backwards
> incompatible, a new PSBT version will be used, v1.
>
> The primary change is to truly have all input and output data for each
> in their respective maps. Instead of having to parse an unsigned
> transaction and lookup some data from there, and other data from the
> correct map, all of the data for an input will be contained in its map.
> Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new version.
> Thus I propose that the following fields be added:
>
> Global:
> * PSBT_GLOBAL_TX_VERSION = 0x02
> ?? * Key: empty
> ?? * Value: 32-bit little endian unsigned integer for the transaction
> version number. Must be provided in PSBT v1 and omitted in v0.
All of these changes sound great. It would definitely make working with
PSBTs easier if all data was accessible in the same format, rather than
being split between the global unsigned tx and the main body.
One minor quibble is the version numbering -- you mention "v1" in this
post but set GLOBAL_TX_VERSION to 2. I think we should consistently use
2 everywhere; probably nobody thinks of the existing PSBT as "version 0".
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201216/244f8942/attachment.sig>

2023-06-07 18:20:59 GMT

- reply

📅 Original date posted:2019-10-09
📝 Original message:On Thu, Oct 03, 2019 at 11:05:52AM -0400, Ethan Heilman wrote:
> To avoid derailing the NO_INPUT conversation, I have changed the
> subject to OP_CAT.
>
> Responding to:
> """
> * `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> par with:
> [..]
> * `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> [..]
> """
>
> OP_CAT is an extremely valuable op code. I understand why it was
> removed as the situation at the time with scripts was dire. However
> most of the protocols I've wanted to build on Bitcoin run into the
> limitation that stack values can not be concatenated. For instance
> TumbleBit would have far smaller transaction sizes if OP_CAT was
> supported in Bitcoin. If it happens to me as a researcher it is
> probably holding other people back as well. If I could wave a magic
> wand and turn on one of the disabled op codes it would be OP_CAT. Of
> course with the change that size of each concatenated value must be 64
> Bytes or less.
>
Just throwing my two cents in here - as others have noted, OP_CAT
lets you create Merkle trees (allowing e.g. log-sized accountable
threshold sigs, at least in a post-Schnorr future).
It also allows manipulating signatures - e.g. forcing the revelation
of discrete logs by requiring the user use the (1/2) point as a nonce
(this starts with 11 zero bytes, which no other computationally
accessible point does), or by requiring two sigs with the same nonce.
It also lets you do proof-of-work-like computations on hashes or
curvepoints; or enforce that EC points come from a hash and have
no known discrete log. You can also switch on hashes, something
currently impossible because of the 4-byte limitation on numeric
opcodes. I don't have specific application of these in mind but
definitely have cut off many lines of inquiry because they were
impossible.
You could build a crappy Lamport signature, though the key would
be so big that you'd never do this pre-MAST :P.
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191009/8edaa1f9/attachment.sig>

2023-06-07 18:20:39 GMT

- reply

📅 Original date posted:2019-09-20
📝 Original message:On Fri, Sep 20, 2019 at 04:54:34AM +1000, Lloyd Fournier via bitcoin-dev wrote:
> Hi ZmnSCPxj,
>
> I can give some context on the exchange during the talk. I was the "Q" and
> Andrew Polestra was the "A".
>
> I followed up with Andrew after and he indeed knew about the pre-signed
> nlocktime transaction double spend technique (actually, I thought he was
> the one who originally came up with that idea for scriptless atomic swaps).
> He clarified saying that you can do that with locktime (absolute time
> locks) but not with sequence numbers (relative time locks). i.e. to enforce
> sequence numbers you need to use OP_CHECKSEQUENCEVERIFY. He said that it
> would make sense to change that so it's enforced regardless of script.
>
> However, I talked to Antoine Riard later who was adamant that sequence
> numbers already worked as expected. He pointed to the fact that BIP68
> already describes it as an independent constraint [1]
>
> So if things do work as described in BIP68 then we should be able to do
> lightning on Bitcoin without any script once we have Schnorr. I'm keen to
> actually figure out all the details of how to do this. It works in my head
> but I think I should write it down somewhere to make sure it works.
>
> [1] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
>
> LL
>
Yep, during the recorded exchange I was confused about the content of
the BIP. Later I described the exchange to Dan Robinson, who showed me
the actual text :).
Sorry for the confusion - Lloyd was totally right and you can do
relative locktimes this way in Taproot without needing to expose a
script.
Having said this, there is the important caveat that your "emergency
backout" keys are online to produce a pre-signed transaction, and
that a suitable destination is known beforehand. This makes sense for
Lightning or most atomic swap protocols where the money simply returns
to the original owner, but not e.g. for Liquid, where the emergency
keys have never been brought online (and anyway the contents of any
transaction they might sign depends on facts and circumstances that
aren't known ahead of time).
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190920/b1a4b294/attachment.sig>

2023-06-07 18:14:28 GMT

- reply

📅 Original date posted:2018-09-05
📝 Original message:On Wed, Sep 05, 2018 at 08:26:14AM -0400, Erik Aronesty wrote:
> Why would you call it FUD? All the weird hemming and hawing about it is
> really strange to me. The more I look into it and speak to professors
> about i, the more it seems "so trivial nobody really talks about it".
>
> 1. Generate an M of N shared public key (done in advance of signing ....
> this gets you the bitcoin address)
> 2. Generate signature fragments (this can be done offline, with no
> communication between participants)
>
> Detailed explanation with code snippets:
>
> https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f
>
The hemming and hawing is because you've been repeatedly told that your
scheme doesn't work, and to please implement it in some computer algebra
system so that you can see that (or so we can see where your mistake is),
and you instead continue to post incomplete/incoherent copies of the same
thing across multiple mediums - Reddit, this list, Bitcointalk, Medium,
etc ad nauseum.
It's distracting and offensive to people who have spent a lot of time and
energy thinking about this stuff, and more importantly it causes confusion
in the public eye. Phrasings like "weird hemming and hawing" suggest that
we don't know/don't care about some insight you have, which is not true.
This is why your posts are FUD.
For example, in your linked post I looked at every single instance of the
character 'k' and *not one of them* defined the value 'k' from which 'R'
is derived in the signing procedure.
Of course there is no possible value, individual signers cannot learn 'R'
at signing time without interaction, and your whole scheme is broken. Given
the number of times you've been told this, I find it hard to believe that
this was an honest mistake.
Andrew
--
Andrew Poelstra
Research Director, Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"Make it stop, my love; we were wrong to try
Never saw what we could unravel in traveling light
Nor how the trip debrides like a stack of slides
All we saw was that time is taller than space is wide"
--Joanna Newsom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180905/8174ffbf/attachment.sig>

2023-06-07 18:12:26 GMT

- reply

📅 Original date posted:2018-05-24
📝 Original message:On Thu, May 24, 2018 at 11:44:16AM +0200, Natanael via bitcoin-dev wrote:
>
> As stated above by Wuille this seems to not be a concern for typical P2SH
> uses, but my argument here is simply that in many cases, not all
> stakeholders in a transaction will hold one of the private keys required to
> sign. And such stakeholders would want a guarantee that the original script
> is followed as promised.
>
In this case, even mandatory graftroot would not allow the signing stakeholders
to take the coins. The reason is that if there are _any_ non-signing script
conditions that must be followed, then to use Taproot the top-level public key
needs to be unusable, e.g. by being a NUMS point. In that case the public key
would also be unusable for Graftroot.
Another way to see this is -- in any context where Graftroot seems dangerous,
there needs to be a reason why the ability to just create transactions is not
dangerous. In your example it seems that the signing parties can just take
the coins with or without Graftroot, so the problem is not in Graftroot but
in the way that the example is set up.
> I'm not concerned by the ability to move funds to an address with the new
> rules that you'd otherwise graftroot in, only that you can provide a
> transparent guarantee that you ALSO follow the original script as promised.
> What happens *after* you have followed the original script is unrelated,
> IMHO.
>
To do this in Taproot you need to disable the top-level key, which will also
disable Graftroot.
--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180524/eb8ee543/attachment.sig>

2023-06-07 18:12:24 GMT

- reply

📅 Original date posted:2018-05-23
📝 Original message:On Wed, May 23, 2018 at 01:50:13PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>
> Graftroot also break blind signature schemes. Consider a protocol such as [1]
> where some party has a bunch of UTXOs all controlled (in part) by the same
> key X. This party produces blind signatures on receipt of new funds, and can
> only verify the number of signatures he produces, not anything about what he
> is signing.
>
> BTW, the same concern holds for SIGHASH_NOINPUT, which I'd also like to be
> disable-able. Maybe we should extend one of ZmnSCPxj's suggestions to include
> a free "flags" byte or two in the witness?
>
> (I also had the same concern about signature aggregation. It seems like it's
> pretty hard to preserve the "one signature = at most one input" invariant of
> Bitcoin, but I think it's important that it is preserved, at least for
> outputs that need it.)
>
> Or maybe, since it appears it will require a space hit to support optional
> graftroot anyway, we should simply not include it in a proposal for Taproot,
> since there would be no opportunity cost (in blockchain efficiency) to doing
> it later.
>
> [1] https://github.com/apoelstra/scriptless-scripts/pull/1
>
On further thought, I rescind this concern (ditto for SIGHASH_NOINPUT) (but
not for aggregate sigs, they still interact badly with blind signatures).
As long as graftroot (and NOINPUT) sigs commit to the public key, it is
possible for a server to have unique keys for every output, even while
retaining the same private key, and thereby ensure that "one sig can spend
only one output" holds. To do this, suppose the server has a BIP32 xpubkey
(xG, cc). A blind signer using the private key x can be made to sign not
only for xG, but also for any publicly-derived child keys of (xG, cc).
Here is a simple scheme that does this:
1. Signer provides a nonce R = kG
2. Challenger computes bip32 tweak h, chooses blinders alpha and beta,
and computes:
R' = R + alpha*G + beta*P
e = H(P + hG || R' || tx)
e' = e + beta
and sends e' to the signer.
3. Signer replies with s = k + xe' (= k + beta*x + (x + h)e - he)
4. Challenger unblinds this as s' = s + alpha + he
(This blind signature scheme is vulnerable to Wagner's attack, though see
Schnorr 2004 [1] for mitigations that are perfectly compatible with this
modified BIP32ish scheme.)
I'm unsure whether key-prefixing is _actually_ necessary for this, but it
makes the security argument much clearer since the messagehash contains
some data which can be made unique per-utxo and is committed in the chain.
Andrew
[1] http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8ECEF929559865FD68D1D873555D18FE?doi=10.1.1.68.9836&rep=rep1&type=pdf
--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180523/5debf87f/attachment-0001.sig>

2023-06-07 18:11:19 GMT

- reply

📅 Original date posted:2018-03-21
📝 Original message:On Wed, Mar 21, 2018 at 02:06:18PM +1000, Anthony Towns via bitcoin-dev wrote:
>
> That leads me to think that interactive signature aggregation is going to
> take a lot of time and work, and it would make sense to do a v1-upgrade
> that's "just" Schnorr (and taproot and MAST and re-enabling opcodes and
> ...) in the meantime. YMMV.
>
Unfortunately I agree. Another complication with aggregate signatures is
that they complicate blind signature protocols such as [1]. In particular
they break the assumption "one signature can spend at most one UTXO"
meaning that a blind signer cannot tell how many coins they're authorizing
with a given signature, even if they've ensured that the key they're using
only controls UTXOs of a fixed value.
This seems solvable with creative use of ZKPs, but the fact that it's even
a problem caught me off guard, and makes me think that signature aggregation
is much harder to think about than e.g. Taproot which does not change
signature semantics at all.
Andrew
[1] https://github.com/jonasnick/scriptless-scripts/blob/blind-swaps/md/partially-blind-swap.md
--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180321/535daaca/attachment.sig>

2023-06-07 18:06:02 GMT

- reply

📅 Original date posted:2017-09-15
📝 Original message:On Fri, Sep 15, 2017 at 10:40:12PM +0200, Simone Bronzini via bitcoin-dev wrote:
> Since a soft-fork is a restriction of the consensus rules, I think the
> only way to have an un-soft-forkable cryptocurrency is creating a
> cryptocurrency where no transaction is valid.
>
Even this can be soft-forked to add an extension block that contains transactions :)
Ultimately I think the best you can do in this direction is to design for
maximal fungibility and/or transaction structures that minimize interaction
with the blockchain. This minimizes the surface for transaction censorship,
which is somewhat in the spirit of your goal.
--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170916/3fa2bec8/attachment.sig>

2023-06-07 18:00:22 GMT

- reply

📅 Original date posted:2017-04-20
📝 Original message:On Thu, Apr 20, 2017 at 11:46:33AM +0200, Tom Zander via bitcoin-dev wrote:
> On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev
> wrote:
> > > I suggested something similar which is a much simpler version;
> > > https://zander.github.io/scaling/Pruning/
>
> > Your proposal has a significant disadvantage: If every peer is dropping
> > 75% of all blocks randomly, then you need to connect to a large number of
> > peers to download the whole blockchain.
> ...
> > If you are downloading 450,000 blocks, you will need to
> > connect to an expected 46 peers to download the whole blockchain.
>
> I don’t really see the problem here, even if your math is a off. (Statistics
> is difficult, I know). Connecting to many nodes to download faster is really
> not an issue and already happens.
>
I think the expected number of peers is actually ~47.75, which is pretty
close to David's estimate, which was wrong in a way that was actually
more favorable to the "everyone stores random blocks" scheme than the
truth.
Even assuming no archival nodes, and all nodes storing only one random
index between 5 and 255 inclusive, the chance of five arbitrary nodes
giving unique indices by chance is about 98.4%. To get the same probability
from a scheme where each peer has only 25% of the blocks, you need to
connect to 59.59 nodes.
This is over a ten-times increase in the number of nodes required to
download the entire chain, and requires participating nodes to use 25%
more space than David's proposal.
> > Your proposal is also a lot less able to handle active adversaries: if
> > nodes are randomly dropping blocks, the probability that one block in
> > particular is dropped by everyone goes up significantly.
>
> You make the assumption that this new mode of pruning will be used by 100%
> of the network, this is not how distributed systems work.
>
Storing random but complete blocks requires the assumption this is _not_ the
case; David's does not make any assumptions. So on top of the performance
considerations there is this potential DoS vector.
--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170420/2fc51438/attachment.sig>

2023-06-07 15:27:06 GMT

- reply

📅 Original date posted:2014-11-03
📝 Original message:On Mon, Nov 03, 2014 at 06:01:46PM +0200, Alex Mizrahi wrote:
>
> Yes, but "harder" isn't same as "unlikely".
>
We are aware of the distintion between hardness (expected work) and
likelihood of successful attack -- much of Appendix B talks about this,
in the context of producing compact SPV proofs which are (a) hard to
forge, and (b) very unlikely to be forgeries.
We did spend some time formalizing this but due to space constraints
(and it being somewhat beside the point of the whitepaper beyond "we
believe it is possible to do"), we did not explore this in as great
depth as we'd have liked.
> Another problem with this section is that it only mentions reorganizations.
> But a fraudulent transfer can happen without a reorganization, as an
> attacker can produce an SPV proof which is totally fake. So this is not
> similar to double-spending, attacker doesn't need to own coins to perform
> an attack.
>
Well, even in the absense of a reorganization, the attacker's false proof
will just be invalidated by a proof of longer work on the real chain.
And there is still a real cost to producing the false proof.
--
Andrew Poelstra
Mathematics Department, University of Texas at Austin
Email: apoelstra at wpsoftware.net
Web: http://www.wpsoftware.net/andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141103/90bfc291/attachment.sig>