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

nprofile1qqswu40tqdprh4xmq82uj2k5xn2jccpdnksaudldxlx9ha7j5yaye2cy878t2

Author Public Key

npub1ae27kq6z802dkqw4ey4dgdx493szm8dpmcm76d7vt0ma9gf6fj4svz5t04

Show more details

Last Notes

2023-09-07 11:52:35

- reply

📅 Original date posted:2023-09-01
🗒️ Summary of this message: The author considered indexing all transactions but decided against it due to increased complexity and potential issues with compressed transactions becoming invalidated. The space savings would be less than a byte per input, not worth the implementation complexity.
📝 Original message:
Hi Fabian,
We did consider indexing all txos -- even, amusingly, by using ordinals --
but decided that the extra index requirements for the decompressor (which
otherwise just requires a bit of extra CPU cycles but nothing beyond a
normal Core node).
A while ago we looked into putting the whole UTXOset into a trie so that
we could do prefix lookups. I think we discarded this idea for the same
reason, and because it could lead to surprising behavior for users since
a compressed tx might get invalidated by some UTXO showing up whose
prefix is too close to one of its inputs. Where "prefix" likely means
some special-purpose hash of the prevout that users will never otherwise
encounter.
We were also a bit put off by the data structure complexity since the
UTXO set no longer fits in RAM so it takes nontrivial effort to
implement a new index :) plus it drops our chances of getting code into
Core by a very large factor.
We can swag what the space savings would be: there are 122MM utxos right
now, which is a bit under 2^27. So assuming a uniform distribution of
prefixes we'd need to specify 28 bits to identify a UTXO. To contrast,
to identify a blockheight we need 20 bits and then maybe 12 more bits to
specify a TXO within a block. Plus whatever varint overhead we have.
(I've been working on this project but busy with family stuff and don't
remember exactly where we landed on the varints for this. I think we
agreed that there was room for improvement but didn't want to hold up
posting the rest of the concept because of it.)
The TL;DR is that we probably save a little less than a byte per input,
on average, which is not trivial but probably not worth the decreased
UX and greatly increased implementation complexity.
Best
Andrew
On Fri, Sep 01, 2023 at 10:24:54AM +0000, Fabian via bitcoin-dev wrote:
> Hi Tom,
>
> without having gone into the details yet, thanks for the great effort you have put into this research and implementation already!
>
> > The bulk of our size savings come from replacing the prevout of each input by a block height and index.
>
> Have you also considered using just an index from a sorted UTXO set instead? The potential additional space saving might be minor but this would make the scheme compatible with pruning. I had this on my list as a future research topic but didn't get around to it yet.
>
> Thanks,
> Fabian
> ------- Original Message -------
> On Thursday, August 31st, 2023 at 11:30 PM, Tom Briar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hey everyone,
> >
> > I've been working on a way to compress bitcoin transactions for transmission throughsteganography, satellite broadcasting,
> > and other low bandwidth channels with high CPU availability on decompression.
> >
> > [compressed_transactions.md](https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md)
> >
> > In the document I describe a compression schema that's tailored for the most common transactions single parties are likely to make.
> > In every case it falls back such that no transaction will become malformed or corrupted.
> > Here's a PR for implementing this schema.
> >
> > [2023 05 tx compression](https://github.com/TomBriar/bitcoin/pull/3)
> > Thanks-
> > Tom.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
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/20230901/9169334e/attachment.sig>

2023-09-07 11:52:34

- reply

📅 Original date posted:2023-08-31
🗒️ Summary of this message: Tom Briar has developed a compression schema for bitcoin transactions that can be transmitted through low bandwidth channels without corruption.
📝 Original message:
On Thu, Aug 31, 2023 at 09:30:16PM +0000, Tom Briar via bitcoin-dev wrote:
> Hey everyone,
>
> I've been working on a way to compress bitcoin transactions for transmission throughsteganography, satellite broadcasting,
> and other low bandwidth channels with high CPU availability on decompression.
>
> [compressed_transactions.md](https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md)
>
> In the document I describe a compression schema that's tailored for the most common transactions single parties are likely to make.
> In every case it falls back such that no transaction will become malformed or corrupted.
> Here's a PR for implementing this schema.
>
> [2023 05 tx compression](https://github.com/TomBriar/bitcoin/pull/3)
Hey Tom,
Thank you for posting this. Could you put together a chart with some
size numbers so we can get a picture of how strong this compression is?
I understand that because this is targeted at stego/satellite
applications where the user is expected to "shape" their transaction,
that you won't get great numbers if you just look at the historical
chain or try to analyze "average" transactions. But it would be great to
post a chart with uncompressed/compressed sizes for "optimum"
transactions. At the very least, a 2-in-2-out wpkh transaction, and a
2-in-2-out Taproot transaction.
Since the scheme includes explicit support for p2sh-wpkh and p2pkh it
would also be great to see numbers for those, though they're less common
and less interesting.
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/20230901/1a0ba0e7/attachment.sig>

2023-08-12 09:56:45

- 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-07-27 00:26:33

- reply

📅 Original date posted:2023-07-26
🗒️ Summary of this message: POSK (proof of secret key) is not a perfect solution for preventing rogue key attacks and has logistical difficulties in implementation.
📝 Original message:
On Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wrote:
> personally, i think *any* time a public key is transmitted, it should come
> with a "proof of secret key". it should be baked-in to low level
> protocols so that people don't accidentally create vulns. alt discussion
> link: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406
>
POSK is not a panacea. For example, if you were to try to eliminate
rogue key attacks in MuSig by using POSK rather than by rerandomizing
the keys, the last person to contribute a key could add a Taproot
commitment to their key, thereby modifying the final key to have a
Taproot spending path that other participants don't know about. If they
did this, they'd have no problem producing a POSK since Taproot
commitments don't affect knowledge of the secret key.
POSKs are also logistically difficult to produce in many contexts. They
essentially require an interactive challege-response (otherwise somebody
could just copy a POSK from some other source), meaning that all
participants need to be online and have secret key access at key setup
time.
In some contexts maybe it's sufficient to have a static POSK. Aside from
the complexity of determining this, you then need a key serialization
format that includes the POSK. There are standard key formats for all
widely used EC keys but none have a facility for this. If you are trying
to use already-published keys that do not have a POSK attached, you are
out of luck.
If your protocol requires POSKs to be provably published, you also run
into difficulties because they don't make sense to embed on-chain (since
blockchain validators don't care about them, and they're twice as big as
the keys themselves) so you need to establish some other publication
medium.
If you want to support nested multisignatures, you need to jointly
produce POSKs, which requires its own protocol complexity.
The MuSig and MuSig2 papers say essentially the same thing as the above;
it's why we put so much effort into developing a scheme which was
provably secure in the plain public key model, which means that POSKs
are superfluous and you don't need to deal with all these logistical
hurdles.
--
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/20230726/84e90df1/attachment.sig>

2023-06-09 12:56:27

- 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/lightning-dev/attachments/20191009/8edaa1f9/attachment.sig>

2023-06-09 12:49:37

- 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-09 12:49:23

- reply

📅 Original date posted:2018-03-06
📝 Original message:
On Tue, Mar 06, 2018 at 08:58:51PM +0000, Andrew Poelstra wrote:
> After creating a new state i, A and B revoke state i-1 as follows:
>
> 3. A sends an adaptor signature for s^2_{A,i-1} which reveals her half
> of AB_i if she publishes that signature. Similarly B sends an
> adaptor sig for s^1_{B,i-1} which reveals his half of AB_{i-1}.
>
> Now if either party completes tx_i and to post the (i-1)th state
> to the chain, the _other_ party will learn the secret key to AB_i
> and can take the coins.
>
Oof I messed up this paragraph. _i should be _{i-1} everywhere. Here is a
correct version:
> 3. A sends an adaptor signature for s^2_{A,i-1} which reveals her half
> of AB_{i-1} if she publishes that signature. Similarly B sends an
> adaptor sig for s^1_{B,i-1} which reveals his half of AB_{i-1}.
>
> Now if either party completes tx_{i-1} to post the (i-1)th state
> to the chain, the _other_ party will learn the secret key to AB_{i-1}
> and can take the coins.
>
--
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/20180306/829279c4/attachment.sig>

2023-06-09 12:49:22

- reply

📅 Original date posted:2018-03-06
📝 Original message:
Hi Anthony,
If you have adaptor/Bellare-Neven signatures you can actually do state updates
in a much simpler way. Suppose we have two parties, Alice and Bob.
The basic structure of a payment channel in state i is
Funding tx --> Commit_i --> Close_i
where Commit_i is a transaction with one output with the following script
IF AB_i ELSE <csv> CSV AB'_i ENDIF CHECKSIG
and Close_i is a transaction moving the coins to their final destination.
(I'm using IF/ELSE, but for efficiency the CSV branch could be hidden behind
a Taproot.)
To create a new state i, A and B interact as follows.
0. Create tx_i, a 1-in-1-out tx which spends the funding tx output to
the Commit_i output.
1. Both sign a closing transaction tx'_i which spends this output to the
Close_i output. tx'_i will be valid <csv> blocks after the Commit
transaction is posted to the blockchain.
2. A and B interactively sign tx_i twice. In the final step of this
interaction, A gives s^1_{A,i} to B and B gives s^2_{B,i} to A.
Now A can generate s^2_{A,i} to complete a signature and post tx_i,
or B can generate s^1_{B,i} to the same effect.
After creating a new state i, A and B revoke state i-1 as follows:
3. A sends an adaptor signature for s^2_{A,i-1} which reveals her half
of AB_i if she publishes that signature. Similarly B sends an
adaptor sig for s^1_{B,i-1} which reveals his half of AB_{i-1}.
Now if either party completes tx_i and to post the (i-1)th state
to the chain, the _other_ party will learn the secret key to AB_i
and can take the coins.
The partial signatures in step (2) can be adaptor signatures which link
this state update to other state updates in other channel, giving complete
paths. In fact you can link arbitrary sets of channels to get multipaths,
so AMP comes for free in this scheme.
As Anthony mentioned in his email, the payment receipt is now a discrete log
(which can be reblinded so that participants in the hop who aren't the sender
or recipient can't see it). This means that the sender can sign with this,
getting a transferrable proof of payment that also works with AMP.
The required state to store consists of these adaptor signatures, so it's
linear in the number of state updates in each channel. I believe outsourcing
will be quadratic :( but I haven't worked out those details. Though you can
get a weak form of monitoring by giving the adaptor signatures to the monitor
and having it contact the affected party with "wake up! somebody published an
old state and revealed the key x, please use it to take your coins".
I haven't worked out blind monitoring either, it seems like it should be
doable because everything here is discrete-log based which is inherently
friendly toward blinding.
Andrew
On Tue, Mar 06, 2018 at 08:18:31PM +0000, Christian Decker wrote:
> ---------- Forwarded message ---------
> From: Anthony Towns <aj at erisian.com.au>
> Date: Mon, Feb 19, 2018 at 11:59 PM
> Subject: [Lightning-dev] Post-Schnorr lightning txes
> To: <lightning-dev at lists.linuxfoundation.org>
>
>
> Hi *,
>
> My understanding of lightning may be out of date, so please forgive
> (or at least correct :) any errors on my behalf.
>
> I was thinking about whether Greg Maxwell's graftroot might solve the
> channel monitoring problem (spoiler: not really) and ended up with maybe
> an interesting take on Schnorr. I don't think I've seen any specific
> writeup of what that might look like, so hopefully at least some of this
> is novel!
>
> I'm assuming familiarity with current thinking on Schnorr sigs -- but all
> you should need to know is the quick summary at footnote [0].
>
> So I think there's four main scenarios for closing a lightning channel:
>
> - both parties are happy to close, do so cooperatively, and can
> sign a new unconditional transaction that they agree on. already fine.
> (should happen almost all of the time, call it 80%)
>
> - communications failure: one side has to close, but the other side
> is happy to cooperate as far as they're able but can only do so via
> the blockchain and maybe with some delay (maybe 15% of the time)
>
> - disappearance, uncooperative: one side effectively completely
> disappears so the other side has to fully close the channel on their
> own (5% of the time)
>
> - misbehaviour: one side tries publishing an old channel state due to
> error or maliciousness, and the other collects the entire balance as
> penalty (0% of the time)
>
> With "graftroot" in mind, I was thinking that optimising for the last
> case might be interesting -- despite expecting it to be vanishingly
> rare. That would have to look something like:
>
> (0) funding tx
> (1) ...which is spent by a misbehaving commitment tx
> (2) ...which is spent by a penalty tx
>
> You do need 3 txes for that case, but you really only need 1 output
> for each: so (0) is 2-in-1-out, (1) is 1-in-1-out, (2) is 1-in-1-out;
> which could all be relatively cheap. (And (2) could be batched with other
> txes making it 1 input in a potentially large tx)
>
> For concreteness, I'm going to treat A as the one doing the penalising,
> and B (Bad?) as the one that's misbehaving.
>
> If you treat each of those txes as a muSig Schnorr pay-to-pubkey, the
> output addresses would be:
>
> (0) funding tx pays to [A,B]
> (1) commitment tx pays to [A(i),Revocation(B,i)]
> (2) pays to A
>
> (where i is a commitment id / counter for the channel state)
>
> If B misbehaves by posting the commitment tx after revealing the
> revocation secret, A can calculate A(i) and Revocation(B,i) and claim
> all the funds immediately.
>
> As far as the other cases go:
>
> - In a cooperative close, you don't publish any commitment txes, you
> just spend the funding to each party's preferred destinations
> directly; so this is already great.
>
> - Otherwise, you need to be able to actually commit to how the funds
> get distributed.
>
> But committing to distributing funds is easy: just jointly sign
> a transaction with [A(i),Revocation(B,i)]. Since B is the one we're
> worrying about misbehaving, it needs to hold a transaction with the
> appropriate outputs that is:
>
> - timelocked to `to_self_delay` blocks/seconds in advance via nSequence
> - signed by A(i)
>
> That ensures A has `to_self_delay` blocks/seconds to penalise misehaviour,
> and that when closing properly, B can complete the signature using the
> current revocation secret.
>
> This means the "appropriate outputs" no longer need the OP_CSV step, which
> should simplify the scripts a bit.
>
> Having B have a distribution transaction isn't enough -- B could vanish
> between publishing the commitment transaction and the distribution
> transaction, leaving A without access to any funds. So A needs a
> corresponding distribution transaction. But because that transaction can
> only be published if B signs and publishes the corresponding commitment
> transaction, the fact that it's published indicates both A and B are
> happy with the channel close -- so this is a semi-cooperative close and
> no delay is needed. So A should hold a partially signed transaction with
> the same outputs:
>
> - without any timelock
> - signed by Revocation(B,i), waiting for signature by A(i)
>
> Thus, if B does a non-cooperative close, either:
>
> - A proves misbehaviour and claims all the funds immediately
> - A agrees that the channel state is correct, signs and publishes
> the un-timelocked distribution transaction, then claims A's outputs;
> B can then immediately claim its outputs
> - A does nothing, and B waits for the `to_self_delay` period, signs
> and publishes its transaction, then claims B's outputs; A can eventually
> claim its own outputs
>
> In that case all of the transactions except the in-flight HTLCs just look
> like simple pay-to-pubkey transactions.
>
> Further, other than the historical secrets no old information needs
> to be retained: misbehaviour can be dealt with (and can only be dealt
> with) by creating a new transaction signed by your own secrets and the
> revocation information.
>
> None of that actually relies on Schnorr-multisig, I think -- it could
> be done today with normal 2-of-2 multisig as far as I can see.
>
>
>
> I'm not 100% sure how this approach works compared to the current one
> for the CSV/CLTV overlap problem. I think any case you could solve by
> obtaining a HTLC-Timeout or HTLC-Success transaction currently, you could
> solve in the above scenario by just updating the channel state to remove
> the HTLC.
>
>
> So I believe the above lets you completely forget info about old HTLCs,
> while still enforcing correct behavior, and also makes enforcing correct
> behaviour cheaper because it's just two extremely simple transactions
> to post. If I haven't missed any corner cases, it also seems to simplify
> the scripts a fair bit.
>
> Does this make sense? It seems to to me...
>
>
> So for completeness, it would make sense to do HTLCs via Schnorr --
> at least to make them reveal elliptic curve private keys, and ideally
> to make them mostly indistinguishable from regular transactions as a
> "scriptless script" [1] or "discreet log contract" [2]. (I think, at
> least for HTLCs, these end up being the same?)
>
> The idea then is to have the HTLC payment hash be R=r*G, where r is the
> secret/payment receipt.
>
> Supposing your current commitment has n HTLCs in-flight, some paying A
> if the HTLC succeeds and "r" is revealed, others paying B. We'll focus
> on one paying A.
>
> So you succeed by A completing a signature that reveals r to B,
> and which simultaneously allows collection of the funds on chain. A
> needs to be able to do this knowing nothing other than r (and their own
> private keys). So agree to sign to muSig 2-of-2 multisig [A,B]. A and B
> generate random values i and j respectively and reveal I=i*G and J=j*G,
> and each calculates Q=I+J+R, and they generate partial signatures of a
> transaction paying A:
>
> I, i + H(X,Q,m)*H(L,A)*a
> J, j + H(X,Q,m)*H(L,B)*b
>
> where L = H(A,B) and X = H(L,A)*A + H(L,B)*B as usual. Once A knows r,
> A can construct a full signature by adding R, r to the above values,
> and B can then determine r by subtracting the above values from signature
> A generated.
>
> To ensure B gets paid if the HTLC timesout, they should also sign a
> timelocked transaction paying B directly, that B can hold onto until
> the channel state gets updated.
>
> And once you're doing payment hashes via ECC, you can of course change
> them at each hop to make it harder to correlate steps in a payment route.
>
> I think that when combined with the above method of handling CSV delays
> and revocation, this covers all the needed cases with a straightforward
> pay-to-pubkey(hash) output, no script info needed at all. It does mean
> each HTLC needs a signature every time the channel state updates (B needs
> to sign a tx allowing A to claim the output once A knows the secret,
> A needs to sign a tx allowing B to claim the output on timeout).
>
>
> For channel monitoring this is pretty good, I think. You need to
> keep track of the revocation info and your secret keys -- but that's
> essentially a constant amount of data.
>
> If you're happy to have the data grow by 64 bytes every time the channel
> state updates, you can outsource channel monitoring: arrange a formula
> for constructing a penalty tx based on the channel commitment tx --
> eg, 95% of the balance goes to me, 4% goes to the monitor's address, 1%
> goes to fees, there's a relative locktime of to_self_delay/3 to allow me
> to directly claim 100% of the funds if I happen to be paying attention;
> then do a partial signature with A(i), and then allow the monitoring
> service to catch fraudulent transactions, work out the appropriate
> revocation secret, and finish the signature.
>
> If your channel updates 100 times a second for an entire year, that's
> 200GB of data, which seems pretty feasible. (You can't just regenerate
> that data though, unless you keep each commitment tx) And it's pretty
> easy to work out which bit of data you need to access: the funding
> tx that's being spent tells you which channel, and the channel state
> index is encoded in the locktime and sequence, so you should only need
> small/logarithmic overhead even for frequently updated channels rather
> than any serious indexes.
>
> I don't think you can do better than that without serious changes to
> bitcoin: if you let the monitoring agency sign on its own, you'd need some
> sort of covenant opcode to ensure it sends any money to you; and with
> segwit outputs, there's no way to provide a signature for a transaction
> without committing to exactly which transaction you're signing.
>
> I was hoping covenants and graftroot would be enough, but I don't
> think they are. The idea would be that since the transaction spends to
> A(i)+Rev(B,i), you'd sign an output script with A that uses covenant
> opcodes to ensure the transaction only pays the appropriate monitoring
> reward, and the monitor could then work out A(i)-A and Rev(B,i) and finish
> the signature. But the signature by "A" would need to know A(i)+Rev(B,i)
> when calculating the hash, and that's different for every commitment
> transaction, so as far as I can see, it just doesn't work. You can't
> drop the muSig-style construction because you need to be protect yourself
> against potential malicious choice of the revocation secret [3].
>
>
> Summary:
>
> - Funding txes as 2-of-2 multisig is still great. Convert to
> Schnorr/muSig when available of course.
>
> - Generate 6+8*n transactions everytime the channel state is updated,
> (n = number of HTLCs in-flight)
>
> 1. Channel state commitment tx, held by A, spends funding tx,
> payable to Schnorr muSig address [A(i),Rev(B,i)], signed by B
> 2. Channel fund distribution tx, held by A (CSV), spends (1),
> signed by Rev(B,i)
> 3. Channel fund distribution tx, held by B (no CSV), spends (1),
> signed by A(i)
> 4. Channel state commitment tx, held by B, spends funding tx
> payable to Schnorr muSig address [B(i),Rev(A,i)], signed by A
> 5. Channel fund distribution tx, held by B (CSV), spends (4),
> signed by Rev(A,i)
> 6. Channel fund distribution tx, held by A (no CSV), spends (4),
> signed by B(i)
>
> The fund distribution txs all pay the same collection of addresses:
> - channel balance for A directly to A's preferred address
> - channel balance for B directly to B's preferred address
> - HTLC balance to muSig address for [A,B] for each in-flight HTLC
> paying A on success
> - HTLC balance to muSig address for [B,A] for each in-flight HTLC
> paying B on success
> - (probably makes sense to bump the HTLC addresses by some random
> value to make it harder for third parties to tell which addresses
> were balances versus HTLCs)
>
> Both (1) and (4) include obscured channel state ids as per current
> standard.
>
> For each HTLC that pays X on timeout and Y on success:
> a. Timeout tx, held by X, signed by Y, spends from (2)
> b. Timeout tx, held by X, signed by Y, spends from (3)
> c. Timeout tx, held by X, signed by Y, spends from (5)
> d. Timeout tx, held by X, signed by Y, spends from (6)
>
> e. Success tx, held by Y, signed by X, spends from (2)
> f. Success tx, held by Y, signed by X, spends from (3)
> g. Success tx, held by Y, signed by X, spends from (5)
> h. Success tx, held by Y, signed by X, spends from (6)
>
> (these should all be able to be SIGHASH_SINGLE, ANYONECANPAY
> to allow some level of aggregation)
>
> - Fund distribution tx outputs can all be pay2pubkey(hash): HTLCs work
> by pre-signed timelocked transactions and scriptless
> scripts/discreet-log contracts to reveal the secret; balances work
> directly; CSV and revocations are already handled by that point
>
> - You can discard all old transaction info and HTLC parameters once
> they're not relevant to the current channel state
>
> - Channel monitoring can be outsourced pretty efficiently -- as little as
> a signature per state could be made to works as far as I can see,
> which doesn't add up too fast.
>
> - There's still no plausible way of doing constant space outsourced
> channel monitoring without some sort of SIGHASH_NOINPUT, at least
> that I can see
>
> Thoughts?
>
> [4]
>
> Cheers,
> aj, very sad that this didn't turn out to be a potential use case for
> graftroot :(
>
> [0] In particular, I'm assuming that:
>
> - Schnorr sigs in bitcoin will look something like:
> R, r + H(X,R,m)*x
>
> (where m is the message being signed by private key x, r is a
> random per-sig nonce, R and X are public keys corresponding to r,x;
> H is the secure hash function)
>
> - muSig is a secure way for untrusting parties to construct an n-of-n
> combined signature; for public keys A and B, it produces a combined
> public key:
> X = H(L,A)*A + H(L,B)*B
> with L = H(A,B)
>
> See
> https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html
>
> [1]
> https://scalingbitcoin.org/stanford2017/Day2/Using-the-Chain-for-what-Chains-are-Good-For.pdf
>
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/using-the-chain-for-what-chains-are-good-for/
>
> [2] https://adiabat.github.io/dlc.pdf
> https://diyhpl.us/wiki/transcripts/discreet-log-contracts/
>
> [3] Well, maybe you could request a zero-knowledge proof to ensure a new
> revocation hash conforms to the standard for generating revocation
> secrets without revealing the secret, and have the public key be
> a(i)*G + r(B,i)*G without using the muSig construct, but that would
> probably be obnoxious to have to generate every time you update
> the channel state.
>
> [4] As an aside -- this could make it feasible and interesting to penalise
> disappearance as well as misbehaviour. If you add a transaction
> the B pre-signs, spending the commitment tx A holds, giving all the
> channel funds to A but only after a very large CSV timeout, perhaps
> `to_self_delay`*50, then the scenarios are:
>
> If A is present:
>
> - B publishes an old commitment: A immediately steals all the
> funds if active or outsourced misbehaviour monitoring. Whoops!
>
> - B publishes the current commitment: A publishes its distribution
> transaction and collects its funds immediately, allowing B to
> do likewise
>
> If A has disappeared:
>
> - B publises the current commitment and waits a modest amount
> of time, publishes its distribution transaction claiming its
> rightful funds, and allowing A to collect its funds if it ever
> does reappear and still knows its secrets
>
> - B publishes the current commitment, waits a fair while,
> A reappears and publishes its distribution transactions, both
> parties get their rightful funds
>
> - B publishes the current commitment, waits an extended period
> of time, and claims the entire channel's funds. If B is
> particularly reputable, and A can prove its identity (but not
> recover all its secrets) maybe B even refunds A some/all of its
> rightful balance
>
> Perhaps that provides too much of an incentive to try blocking
> someone from having access to the blockchain though.
>
> _______________________________________________
> 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/20180306/ed21a545/attachment-0001.sig>

2023-06-07 23:20:22

- reply

📅 Original date posted:2023-04-05
🗒️ Summary of this message: Murch has proposed an informational BIP to establish a shared vocabulary for various components and aspects of transactions to avoid confusion.
📝 Original message:On Wed, Apr 05, 2023 at 02:54:15PM -0400, Murch via bitcoin-dev wrote:
> Hey everyone,
>
> Over the years, I have participated in a few conversations about various
> aspects of transactions. Often a chunk of the conversation is spent on
> establishing a shared vocabulary. There are many competing terms—e.g. I can
> think of at least three additional terms that refer to `scriptPubKey`.
>
> I’ve drafted an informational BIP that proposes terminology for various
> components and aspects of transactions. As some established terms are
> already contradictory, the proposal does not aim for a perfectly consistent
> selection of terms, but rather just to establish a shared vocabulary to
> avoid confusion.
>
> Draft: https://github.com/Xekyo/bips/pull/1
>
> Please let me know whether you’d be interested in the creation of such a
> BIP.
>
I would be interested in such a BIP existing.
I will leave to others the hard work of bikeshedding every single term.
Cheers
--
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/20230405/69c926e9/attachment.sig>

2023-06-07 23:19:48

- 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:43

- reply

📅 Original date posted:2023-02-19
🗒️ Summary of this message: A new proposal for generating and encoding Bitcoin private keys has been introduced, with benefits including a more compact encoding and the ability to verify the integrity of each share independently without using a computer. However, the proposal does not support passphrases or hardening of any form, and has no hardware wallet support.
📝 Original message:On Sun, Feb 19, 2023 at 10:13:33AM -1000, David A. Harding wrote:
> On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:
> > the draft lists several benefits over SLIP-0039.
>
> The only benefit over SLIP39 that I see explicitly mentioned in the
> draft BIP is "simple enough for hand computation". In the FAQ[1] on the
> project's website, I see some additional reasons:
>
Oh, you're right! I think we removed this text in one of our revisions.
I'll see if it makes sense to put it back.
> | This scheme is essentially the same as SLIP39, with the following
> differences:
> |
> | - The checksum is longer, slightly stronger, and designed to be
> | computable by hand.
> |
> | - Our encoding is more compact, giving us room for a bit of more
> | metadata, which is also designed to be readable by hand.
> |
> | - Unlike SLIP39, we do not support passphrases or hardening of any
> | form.
> |
> | - Unlike SLIP39, we have no hardware wallet support. But we hope that
> | will change!
>
These are roughly the benefits -- a more compact encoding which is
always a fixed width. We also list "not supporting features such as
passphrases" as a benefit, for users who don't need/want this.
> <snip>
>
> When I first saw the post about this, it was unclear to me that it was a
> serious project, but I've become increasingly interested as I researched
> it. I'm not personally that interested in generating entropy from dice
> or encoding shares by hand---it's already imperative that I acquire a
> trustworthy computer and load it with trustworthy software in order to
> use my seed securely, so I might as well have it generate my seeds and my
> recovery codes for me.
>
Yes, we've been a bit coy about how serious this project is, because on
its face it's such a silly thing. But for my part, I've been using it
for real coins for over a year and I consider it to be serious.
> What really did catch my attention, but which was kind of buried in the
> project documentation, is the ability to verify the integrity of each
> share independently without using a computer. For example, if I store a
> share with some relative who lives thousands of kilometers away, I'll be
> able to take that share out of its tamper-evident bag on my annual
> holiday visit, verify that I can still read it accurately by validating
> its checksum, and put it into a new bag for another year. For this
> procedure, I don't need to bring copies of any of my other shares,
> allowing them (and my seed) to stay safe.
>
This is good feedback. I strongly agree that this is the big selling
point for this -- that you can vet shares/seeds which *aren't* being
actively used, without exposing them to the sorts of threats associated
with active use.
We should make this more prominent in the BIP motivation.
>
> I do have one question after watching an excellent video[2] about the
> motivation for this system. In the video, one of the threat models
> described is a disarrangement of the words in a metal backup system.
> The implication seems to be that this would be an accidental
> disarrangement, which obviously the Codex32 checksum would catch during
> periodic offline verification. But what about deliberate modification
> of a recovery code? For example, Bob doesn't keep his seed loaded on
> any computer; it only exists in Codex32 shares which Bob plans to
> combine together in 20 years when he retires, although he makes regular
> deposits to the pubkeys derived from the seed's master xpub. Mallory is
> able to obtain access to Bob's shares, allowing her to immediately steal
> his current funds---but also allowing her to replace them with
> similar-looking
> shares with the same metadata and valid checksums so that Bob
> continues making deposits to the wallet.
>
> I'm curious about whether there's a way to prevent this attack without
> otherwise compromising the properties of the code? For example, some
> extra data that Bob can carry around (or memorize) for verifying the
> shares haven't changed, but which is not otherwise needed for recovery
> (so there's no problem if it's lost).
>
Unfortunately not, as near as I can tell ... one way to think of this is
that Alice can flip a lot of random tiles then "error correct" it to get
a new valid, but incorrect, seed. So as long as we support error
correction it'll be possible to wreck seeds in this way.
It's actually even worse than this ... as long as there's a clearly
defined "checksum" at the end of a share, Alice will be able to mangele
tiles and then just re-compute the checksum at the end.
So what we really need to prevent this is something like a MAC: where
Bob has a secret value which gets input into the checksum somehow, which
Alice can't create valid checksums without knowing. Unfortunately I
don't see any way to do this with linear codes. With a hash-based
"checksum" a la BIP39 it would definitely be possible, but of course,
not hand-computable.
BTW, to execute this attack Alice doesn't need to compromise *all* the
shares. Just enough that Bob no longer has threshold-many un-tampered
ones left.
--
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/20230219/56f6c656/attachment-0001.sig>

2023-06-07 23:19:41

- reply

📅 Original date posted:2023-02-16
🗒️ Summary of this message: A proposed Bitcoin Improvement Proposal (BIP) aims to simplify hand computation for users, but its benefits over an existing standard are not substantial.
📝 Original message:On Thu, Feb 16, 2023 at 12:50:12PM +0100, Pavol Rusnak via bitcoin-dev wrote:
> Hi!
>
> The BIP states that its only advantage over SLIP-0039, which has been used
> in production for nearly three years (in at at least 3 SW/HW wallet
> implementations), is that it aims to be simple enough for hand computation.
> However, the BIP also indicates that "details of hand computation are
> outside the scope of this standard, and implementers do not need to be
> concerned with this possibility." Therefore, I am curious about how
> significant this advantage over SLIP-0039 really is. If hand computation is
> not straightforward and there are no other substantial advantages over
> SLIP-0039, I cannot help but feel that this BIP is simply a result of
> not-invented-here syndrome, but please correct me if I am wrong.
>
In my view, the hand computation is actually the main benefit of this
scheme. The process *is* straightforward, but tedious enough (and the
security benefits obscure enough, though they really shouldn't be...
"computers are opaque and untrustworthy" should be a common sentiment)
that it's hard to expect more than a small absolute number of users to
actually do it.
But for the purpose of the *standard*, what is important is that it is
possible to implement and use this within a normal hww workflow. This is
important for hand-computing users who know that their coins will not
die with them (since the 'standard' has fallen into obscurity), and
important for "normal" users who have the option to seamlessly switch
over to hand computation as the BTC price goes up or the world becomes
scarier.
For what it's worth, the draft lists several benefits over SLIP-0039.
I agree that none of them are particularly strong [1], and even together
they probably wouldn't meet the threshold to take the time to write a
standard, but I assure you the motivation was not NIH :).
> Keep in mind that the encoded shares in SLIP-0039 consist of exactly 200 or
> 330 bits, both of which are divisible by 5. This makes it straightforward
> to encode them as Bech32 strings.
>
This is true! And very convenient for people who may want to simply
"layer on" the codex32 checksum/splitting logic onto their SLIP39 words.
They can use a lookup table to do the conversion, spend years or
whataever doing hand-computation on them, and then use a lookup table
to go back.
[1] One listed reason is that "a SLIP is not a BIP". I have heard people
speculate that this is one reason SLIP-0039 is not nearly as
widespread as BIP-0039, even though it is objectively a far better
standard. I'm unsure whether I believe this, but "there is no other
BIP" does seem like a good reason for BIP-0039's continued
dominance.
At the very least, it means that on BIP-0039 itself we have nothing
that we could say "supercedes" or "is recommended instead of" the
BIP. See https://github.com/bitcoin/bips/pull/1413
So it's something of an aside, but I think it would probably be good
for the ecosystem (though maybe bad for this BIP's prospects :)) if
you would request a BIP number for SLIP-0039.
--
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/20230216/7f6aa147/attachment.sig>

2023-06-07 23:19:36

- 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:35

- reply

📅 Original date posted:2023-02-17
🗒️ Summary of this message: Andrew Poelstra discusses the potential issues with banning specific script fragments in Bitcoin and suggests an alternative solution.
📝 Original message:On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>
> 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.
>
I realize this is confusingly worded. I mean, they'd provide the `FALSE`
as a separate witness element rather than being part of the witnessScript.
--
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/ac844572/attachment.sig>

2023-06-07 23:19:34

- 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:28

- reply

📅 Original date posted:2023-02-08
🗒️ Summary of this message: A potential bug in Taproot allows the same Tapleaf to be repeated multiple times in the same Taproot, which could incur different Tapfee rates.
📝 Original message:On Wed, Feb 08, 2023 at 09:34:57AM +0000, 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].
>
I'm actually not certain what Russell's referring to, but if it's indeed
possible to construct TapTrees where the "same" leafhash appears multiple
times at different heights, that's something unintended and which we
could've fixed by changing the Merkle structure. I don't even think
there would've been an efficiency tradeoff.
So I think it's totally reasonable to call such a thing a "bug".
--
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/20230208/81f97b92/attachment.sig>

2023-06-07 23:19:26

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: Miniscript can help prevent an attack in multiparty transactions where the last input uses a larger signature to extract a fee from other parties. It allows participants to determine the maximum witness size and sign under specific conditions. Taproot also has a maximum signature size of 65 bytes, reducing the potential for this attack. However, there are still some cases where the attack can occur, but Miniscript provides tools to identify and mitigate the risk.
📝 Original message:On Tue, Feb 07, 2023 at 04:49:28AM +0200, Yuval Kogman via bitcoin-dev wrote:
>
> Since Taproot (more generally any kind of MAST) spends have variable size which
> depends on the path being used, the last such input to be signed in a multiparty
> transaction can always use a larger than estimated signature to unfairly extract
> a fee contribution from the other parties to the transaction (keeping the
> absolute fees the same and reducing the feerate for the transaction).
>
Using Miniscript [1] it is possible for all participants to determine
the maximum witness size of the tree, which can bound the size of this
attack. In fact, they can bound the size *given that their own signature
is used*, or subject to other whatever other conditions they would like,
and only sign under those conditions.
Furthermore, under Taproot individual signatures have a maximum size of
65 bytes; an "attacker" can reduce this to 64 by not including a sighash
flag, but he has one byte of play. (Pre-Taproot signatures could take up
to 73 bytes with significant room to reduce this by using crypto tricks
and/or grinding).
Peter Todd also suggests in this thread that the use of uncompressed
keys can cause "surprise" witness inflation, but (a) since segwit
uncompressed keys are also banned, so keys are a fixed 33 bytes (32 in
Taproot), and (b) we expect users of Miniscript to always know all the
keys used in a script that they're signing. Except perhaps in obscure
cases where, say, the "victim" is a somewhat passive countersigner of
a transaction, e.g. BitGo, ... in which case they're not the one putting
up fees or with an interest in the transaction going through.
With Miniscript, the problem is narrower:
* There is some more-expensive branch that could be taken without
Alice's signature. In which case Alice is only signing at all to
optimistically reduce the witness size... but she cannot assume
that she is going to be successful!
Notably, in this case Alice does not really have any interest in the
coins, in the sense that they can move entirely without her consent,
so it's hard to imagine that she has an interest in the transaction's
speedy confirmation.
* There is some more-expensive branch that could be taken by moving
Alice's signature. This is the case that you identify in the thread.
While the attack remains in both cases, fortunately Miniscript gives
Alice the tools to (a) determine which, if any, case applies to the
script under question, and (b) determine what the maximum witness size
might be, and just sign assuming that, treating any savings as "bonus".
[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!
If you want to prevent signatures from moving around *within* a
branch,
--
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/20230207/bd1c6f4e/attachment.sig>

2023-06-07 23:19:26

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: Andrew Poelstra discusses Taproot's CODESEPARATOR opcode and the prevention of signature migration between tapbranches in his recent email.
📝 Original message:Some people highlighted some minor problems with my last email:
On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>
> <snip>
>
> [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
-------------- 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/20230207/8d59f739/attachment.sig>

2023-06-07 23:19:04

- 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

- 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:18:48

- reply

📅 Original date posted:2023-01-27
🗒️ Summary of this message: A developer is questioning the wisdom of allowing unlimited storage of NFT content as witness data on the Bitcoin blockchain, but there is no sensible way to prevent it. Arbitrary data storage in witnesses cannot be banned without incentivizing worse behavior or breaking legitimate use cases. While there is a reasonable argument that such data is toxic to the network, there is no principled way to stop it.
📝 Original message:On Fri, Jan 27, 2023 at 09:44:10AM -0300, Robert Dickinson via bitcoin-dev wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal
> scheme is elegant and genius IMHO, but when I think about the future disk
> use of all unpruned nodes, I question whether unlimited storage is wise to
> allow for such use cases. Wouldn't it be better to find a way to impose a
> size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal construct
> for proof of ownership in the real world, so that real property can be
> transferred on the blockchain using ordinals, but storing the property
> itself on the blockchain seems nonsensical to me.
Unfortunately, as near as I can tell there is no sensible way to prevent
people from storing arbitrary data in witnesses without incentivizing
even worse behavior and/or breaking legitimate use cases.
If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).
But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable.
There's a reasonable argument that this sort of data is toxic to the
network, since even though "the market is willing to bear" the price of
scares blockspace, if people were storing NFTs and other crap on the
chain, then the Bitcoin fee market would become entangled with random
pump&dump markets, undermining legitimate use cases and potentially
preventing new technology like LN from gaining a strong foothold. But
from a technical point of view, I don't see any principled way to stop
this.
--
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/20230127/1ca9b7cf/attachment.sig>

2023-06-07 23:14:05

- 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

- 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

- 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:58:14

- reply

📅 Original date posted:2021-08-24
📝 Original message:Simplicity does not compile to Bitcoin Script, and Sapio assumes extensions
to Bitcoin Script that are not currently part of the consensus code.
On Tue, Aug 24, 2021 at 03:36:29PM +0800, Gijs van Dam via bitcoin-dev wrote:
> Hi,
>
>
> Bitcoin does not have a virtual machine. But you do have [Miniscript][1],
> [Min.sc][2], [Simplicity][3] and [Sapio][4]. These are all higher level
> languages that compile to Bitcoin Script. Sapio is "just" Rust, so that
> might fit your setting best.
>
> By the way, this question also has an answer on [Bitcoin Stackexchange][5]
> which is a great resource for questions like this.
>
> [1]: http://bitcoin.sipa.be/miniscript/
> [2]: https://min.sc/
> [3]: https://github.com/ElementsProject/simplicity
> [4]: https://learn.sapio-lang.org/
> [5]:
> https://bitcoin.stackexchange.com/questions/108261/is-there-a-tool-like-ethereum-evm-at-present-for-bitcoin-script
>
> On Tue, Aug 24, 2021 at 2:55 PM Null Null via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hi all,
> >
> > Is there a tool like Ethereum EVM at present? Users can write bitcoin
> > scripts in a syntax just like python(or like other programming language);
> > through this tool, they can be translated into bitcoin original scripts; it
> > sounds like a new programming language has been invented.
> >
> > In my opinion， Bitcoin script programming is based on reverse Polish
> > expression; this is not friendly to programmers;
> >
> > In fact, Bitcoin's opcode expression ability is very rich, and it may be
> > unfriendly, which has affected the promotion of Bitcoin in the technical
> > community.
> >
> > Hope for hearing some voice about this.
> >
> > Best wish.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
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 22:51:43

- 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 22:51:32

- reply

📅 Original date posted:2021-04-08
📝 Original message:On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
>
> All of this makes me extremely uncomfortable and I dread to think what
> individuals and businesses all over the world who have plans to
> utilize and build on Taproot are making of all of this. As an
> individual I would like to distance myself from this circus. I will
> try to keep the mailing list informed though of further developments
> re Speedy Trial in Core or progress on an alternative client.
>
Thank you for your updates.
For what it's worth, as somebody who wants to use Taproot I don't care *at
all* about activation parameters, and I especially don't care about block
height vs MTP.
If a coin toss is what it takes for people to move past this that's fine
by me.
--
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:31:35

- reply

2023-06-07 18:31:26

- reply

2023-06-07 18:30:57

- 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:55

- reply

📅 Original date posted:2021-03-15
📝 Original message:On Mon, Mar 15, 2021 at 09:48:15PM +0000, Luke Dashjr via bitcoin-dev wrote:
> Also, what I didn't know myself until today, is that we do not actually gain
> anything from this: the features proposed to make use of the raw keys being
> public prior to spending can be implemented with hashed keys as well.
> It would use significantly more CPU time and bandwidth (between private
> parties, not on-chain), but there should be no shortage of that for anyone
> running a full node (indeed, CPU time is freed up by Taproot!); at worst, it
> would create an incentive for more people to use their own full node, which
> is a good thing!
>
"No gain" except to save significant CPU time and bandwidth? As Matt points
out there is also a storage hit (unless you want to _really_ waste CPU time
by using pubkey recovery, eliminating any hope of batch validation while
introducing a new dependency on an algorithm with a very unclear patent
story).
Having exposed keys also lets you do ring signatures over outputs, creating the
ability to do private proof of funds via Provisions.
> 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.
> 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%.
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.
--
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/20210315/386e13df/attachment.sig>

2023-06-07 18:30:54

- 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:53

- reply

📅 Original date posted:2020-12-23
📝 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've updated my PR at https://github.com/bitcoin/bips/pull/1048
Differences:
1. I compacted all the validation states into three: valid at time/age T/S, invalid,
and inconclusive.
2. "Inconclusive" means either an "upgradeable rule" failed, e.g. use of a NOP or a
bad network version, or the validator just didn't understand the scripts.
3. I removed the "Extensions" sections now everything is in the main protocol.
4. I removed the "to_sign" transaction from the wire serialization, since after all
this, it can always be inferred from the message and address. (This does mean,
however, that there is no way to sign for scriptPubKeys that don't have addresses,
e.g. bare public keys or multisigs. I don't think it's worth complicated the
protocol for such obscure things.)
--
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/858f723b/attachment.sig>

2023-06-07 18:27:52

- 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

- 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

- 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

- 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

- 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

- 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:16:42

- reply

📅 Original date posted:2019-03-06
📝 Original message:Hi all,
I'd like to start initial discussion about an extension to BIP174 [1] to add
some fields that I've found myself wanting when using PSBT in practice. For
now I'll just list the things that I'd like to see, and if we can come up
with a stable list then I'll try to write up a more formal draft.
Basically I'd just like to add some more fixed data fields.
1. Add an field to PSBT_GLOBAL_UNSIGNED_TX to the global table which contains
just a txid of the unsigned transaction, for bandwidth savings in case
signers have already seen the tx or can construct it themselves.
This field would be fixed 32 bytes.
(This would actually be a breaking change since the current PSBT rules require
PSBT_GLOBAL_UNSIGNED_TX to always be present. Maybe this is a no-go for that
reason alone.)
2. Add a version field to the global table.
3. Add fields to the per-input tables for
(a) confirmed depth of the referenced txout; this is useful for finalizers
trying to create optimized witnesses, for e.g. cases when CSV timeouts
expire and some signatures become unnecessary.
This field must be a varint.
(b) a map from SHA2 hashes to their 32-byte preimages; this field must be
fixed 32 bytes. This, plus the CSV thing, would allow writing finalizers
that work with all of Miniscript [2].
(c) a map from public keys to 32-byte "tweaks" that are used in the pay-to-contract
construction. Selfishly I'd like this to be a variable-length bytestring
with the semantics that (a) the first 33 bytes represent an untweaked
pubkey; (b) the HMAC-SHA256 of the whole thing, when multiplied by G and
added to the untweaked pubkey, result in the target key. This matches the
algorithm in [3] which is deployed in Blockstream's Liquid, but I'd be
happy with a more efficient scheme which e.g. used SHA256 rather than
HMAC-SHA256.
(d) maps from public keys to partial nonce commitments, partial nonces, and
partial signatures, for MuSig [4] support.
(e) a map from signatures (or signature nonces?) to sign-to-contract tweaks.
Same semantics as (c) above.
The last two suggestions are probably premature and need further development
and standardization of the related protocols. But I'm throwing them in to see
if other people have strong feelings about this.
4. Add fields to the per-output tables for pay-to-contract, like in (c) above.
5. Add a field (or rather, family of fields) to every table which is "proprietary
use" and guaranteed not to be defined by any future PSBT extension. Specifically
every field with key-type 0xFF could be considered "proprietary".
5a. The special field in the global table whose key is only 0xFF should be a
"proprietary version field" with unspecified semantics but an understanding
that specific users might stick a GUID or something in there as a way to
recognize their own PSBTs.
[1] https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Encoding
[2] http://bitcoin.sipa.be/miniscript/miniscript.html
[3] https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/validation.cpp
[4] https://eprint.iacr.org/2018/068
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"There are some mornings when the sky looks like a road
There are some dragons who were built to have and hold
And some machines are dropped from great heights lovingly
And some great bellies ache with many bumblebees
And they sting so terribly"
--Joanna Newsom

2023-06-07 18:14:30

- reply

📅 Original date posted:2018-09-13
📝 Original message:On Tue, Sep 11, 2018 at 01:37:59PM -0400, Erik Aronesty via bitcoin-dev wrote:
> - Musig, by being M of M, is inherently prone to loss.
>
It has always been possible to create M-of-N threshold MuSig signatures for any
M, N with 0 < M ≤ N. This is (a) obvious, (b) in our paper, (c) implemented at
https://github.com/apoelstra/secp256k1/blob/2018-04-taproot/src/modules/musig/main_impl.h
--
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/20180913/ca7797a6/attachment.sig>

2023-06-07 18:14:30

- reply

📅 Original date posted:2018-09-14
📝 Original message:Hi Erik,
Sorry, you're right - I thought we mentioned m-of-n as a footnote but that was
actually in the earlier pre-MuSig version of our multisig paper.
Threshold signatures -are- mentioned in the BIP which started this thread, though.
At https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki we say
"Further, by combining Schnorr signatures with Pedersen Secret Sharing,
it is possible to obtain an interactive threshold signature scheme that
ensures that signatures can only be produced by arbitrary but predetermined
sets of signers. For example, k-of-n threshold signatures can be realized
this way. Furthermore, it is possible to replace the combination of
participant keys in this scheme with MuSig, though the security of that
combination still needs analysis.
and this combination of MuSig and VSS is exactly what is implemented in my code.
Cheers
Andrew
On Thu, Sep 13, 2018 at 04:20:36PM -0400, Erik Aronesty wrote:
> The paper refers to either:
>
> a) building up threshold signatures via concatenation, or. implicitly -
> in Bitcoin -
> b) by indicating that of M of N are valid, and requiring a validator to
> validate one of the permutations of M that signed - as opposed to a scheme,
> like a polynomial function, where the threshold is built in to the system.
>
> Maybe there's another mechanism in there that I'm not aware of - because
> it's just too simple to mention?
>
> - Erik
>
>
>
>
>
>
> On Thu, Sep 13, 2018 at 2:46 PM Andrew Poelstra <apoelstra at wpsoftware.net>
> wrote:
>
> > On Tue, Sep 11, 2018 at 01:37:59PM -0400, Erik Aronesty via bitcoin-dev
> > wrote:
> > > - Musig, by being M of M, is inherently prone to loss.
> > >
> >
> > It has always been possible to create M-of-N threshold MuSig signatures
> > for any
> > M, N with 0 < M ≤ N. This is (a) obvious, (b) in our paper, (c)
> > implemented at
> >
> >
> > https://github.com/apoelstra/secp256k1/blob/2018-04-taproot/src/modules/musig/main_impl.h
> >
> > --
> > 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
> >
> >
--
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/20180914/498c9bc5/attachment.sig>

2023-06-07 18:14:28

- 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:14:27

- reply

📅 Original date posted:2018-09-02
📝 Original message:On Wed, Aug 29, 2018 at 08:09:36AM -0400, Erik Aronesty wrote:
> Note:
>
> This spec cannot be used directly with a shamir scheme to produce
> single-round threshold multisigs, because shares of point R would need to
> be broadcast to share participants in order to produce valid single
> signatures.
>
> (R, s) schemes can still be used "online", if share participants publish
> the R(share).... but, not sure if it matter much, this choice eliminates
> offline multiparty signing in exchange for batch validation.
>
Please stop with this FUD. No tradeoff was made. There are no non-interactive
Schnorr signatures.
Andrew
--
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/20180903/cec88ce8/attachment-0001.sig>

2023-06-07 18:13:57

- reply

📅 Original date posted:2018-08-12
📝 Original message:I think it's just an oversight. We should specify that we use the standard
encoding from section 2.3 of http://www.secg.org/sec1-v2.pdf except that
we allow only compressed public keys.
Andrew
On Mon, Aug 06, 2018 at 11:12:48PM +0200, Tim Ruffing via bitcoin-dev wrote:
> Is it intentional that the encoding of public (and private) keys is
> unspecified? I'd consider at least the encoding of the public key to be
> part of the signature scheme, so ideally it should be specified already
> in this BIP. On the other hand, there may be good arguments against it,
> but I'm not aware of any.
>
> This issue leads to a discrepancy between the specification and the
> test vectors because the data fields of test vectors "are given as byte
> arrays", including public and secret key. As a consequence, even the
> Python reference implementation in the BIP draft doesn't work on test
> vectors (in a strict sense).
>
> Best,
> Tim
>
>
> On Fri, 2018-07-06 at 11:08 -0700, Pieter Wuille via bitcoin-dev wrote:
> > Hello everyone,
> >
> > Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> > over the same curve as is currently used in ECDSA:
> > https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> >
> > It is simply a draft specification of the signature scheme itself. It
> > does not concern consensus rules, aggregation, or any other
> > integration into Bitcoin - those things are left for other proposals,
> > which can refer to this scheme if desirable. Standardizing the
> > signature scheme is a first step towards that, and as it may be
> > useful
> > in other contexts to have a common Schnorr scheme available, it is
> > its
> > own informational BIP.
> >
> > If accepted, we'll work on more production-ready reference
> > implementations and tests.
> >
> > This is joint work with several people listed in the document.
> >
> > Cheers,
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-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/bitcoin-dev/attachments/20180812/1a5026a0/attachment.sig>

2023-06-07 18:12:26

- 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

- 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:12:24

- reply

📅 Original date posted:2018-05-23
📝 Original message:On Tue, May 22, 2018 at 11:17:42AM -0700, Pieter Wuille via bitcoin-dev wrote:
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no strong
> reasons why this would be necessary, but I'd like to hear other
> people's thoughts.
>
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
--
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/fe3efcc5/attachment.sig>

2023-06-07 18:11:19

- 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:10:09

- reply

📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 10:45:06PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns <aj at erisian.com.au> wrote:
> > Hmm, at least people can choose not to reuse addresses currently --
> > if everyone were using taproot and that didn't involve hashing the key,
>
> Can you show me a model of quantum computation that is conjectured to
> be able to solve the discrete log problem but which would take longer
> than fractions of a second to do so? Quantum computation has to occur
> within the coherence lifetime of the system.
>
> > way for individuals to hedge against quantum attacks in case they're ever feasible, at least that I can see (well, without moving their funds out of bitcoin anyway)?
>
> By using scriptpubkeys with actual security against quantum computers
> instead of snake-oil.
>
> > (It seems like using the point at infinity wouldn't work because
>
> Indeed, that doesn't work.
>
> > that when quantum attacks start approaching feasibility. If funds are
> > being held in reused addresses over the long term, that would be more
>
> They are. But I don't believe that is relevant; the attacker would
> simply steal the coins on spend.
Then the system would need to be hardforked to allow spending through a
quantum-resistant ZKP of knowledge of the hashed public key. I expect
that in a post-quantum world there will be demand for such a fork,
especially if we came into such a world through surprise evidence of
a discrete log break.
--
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/20180124/73e08261/attachment.sig>

2023-06-07 18:08:17

- reply

📅 Original date posted:2017-12-04
📝 Original message:To follow up on the remarkable work Greg announced from Benedikt Bünz (Stanford)
and Jonathan Bootle (UCL) on Bulletproofs: https://eprint.iacr.org/2017/1066
Summary
=========
Over the last couple weeks, along with Jonas Nick, Pieter Wuille, Greg Maxwell
and Peter Dettmann, I've implemented the single-output version of Bulletproofs
at https://github.com/ElementsProject/secp256k1-zkp/pull/16 and have some
performance numbers.
All of these benchmarks were performed on one core of an Intel i7-6820MQ
throttled to 2.00Ghz, and reflect verification of a single 64-bit rangeproof.
Old Rangeproof 14.592 ms
with endo 10.304 ms
Bulletproof 4.208 ms
with endo 4.031 ms
ECDSA verify 0.117 ms
with endo 0.084 ms
Here "with endo" refers to use of the GLV endomorphism supported by the curve
secp256k1, which libsecp256k1 (and therefore Bitcoin) supports but does not
enable by default, out of an abundance of caution regarding potential patents.
As we can see, without the endomorphism this reflects a 3.47x speedup over
the verification speed of the old rangeproofs. Because Bulletproof verification
scales with O(N/log(N)) while the old rangeproof scales with O(N), we can
extrapolate forward to say that a 2-output aggregate would verify with 4.10x
the speed of the old rangeproofs.
By the way, even without aggregation, we can verify two rangeproofs nearly 15%
faster than verifying one twice (so a 3.95x speedup) because the nature of the
verification equation makes it amenable to batch verification. This number
improves with the more proofs that you're verifying simultaneously (assuming
you have enough RAM), such that for example you can batch-verify 10000
bulletproofs 9.9 times as fast as you could verify 10000 of the old proofs.
While this is a remarkable speedup which greatly improves the feasibility of
CT for Bitcoin (though still not to the point where I'd expect a serious
proposal to get anywhere, IMHO), the concerns highlighted by Greg regarding
unconditional versus computational soundness remain. I won't expand on that
more than it has already been discussed in this thread, I just want to tamp
down any irrational exhuberance about these result.
People who only care about numbers can stop reading here. What follows is a
discussion about how this speedup is possible and why we weren't initially
sure that we'd get any speedup at all.
Details
=========
Section 6 of the linked preprint discusses performance vs our old rangeproofs. As
Greg mentioned, it is possible to fit two 64-bit bulletproofs into 738 bytes,
with logarithmic scaling. (So one proof would take 674 bytes, but eight proofs
only 866 bytes.)
However, this section does not give performance numbers, because at the time
the preprint was written, there was no optimized implementation on which to
benchmark. It was known that verification time would be roughly linear in the
size of the proof: 141 scalar-multiplies for a 64-bit proof, 270 for an
aggregate of two proofs, and so on [*]. Our old rangeproofs required only 128
multiplies for a 64-bit proof, then 256 for two, and so on. So naively we were
concerned that the new Bulletproofs, despite being fantastically smaller than
the original rangeproofs, might wind up taking a bit longer to verify.
For reference, an ordinary ECDSA signature verification involves 2 multiplies.
So roughly speaking, the naive expectation was that a N-bit rangeproof would
require N-many signature verifications' worth of CPU time, even with this new
research. Worse, we initially expected bulletproofs to require 1.5x this much,
which we avoided with a trick that I'll describe at the end of this mail.
As you can see in the above numbers, the old rangeproofs actually perform worse
than this expectation, while the new Bulletproofs perform significantly **better**.
These are for the same reason: when performing a series of scalar multiplications
of the form
a*G + b*H + c*I + ...
where G, H, I are curvepoints and a, b, c are scalars, it is possible to compute
this sum much more quickly than simply computing a*G, b*H, c*I separately and
then adding the results. Signature validation takes advantage of this speedup,
using a technique called Strauss' algorithm, to compute the sum of two multiplies
much faster than twice the multiple-speed. Similarly, as we have learned, the
141 scalar-multiplies in a single-output Bulletproof can also be done in a single
sum. To contrast, the old rangeproofs required we do each multiplication separately,
as the result of one would be hashed to determine the multiplier for the next.
libsecp256k1 has supported Strauss' algorithm for two points since its inception
in 2013, since this was needed for ECDSA verification. Extending it to many points
was a nontrivial task which Pieter, Greg and Jonas Nick took on this year as part
of our aggregate signatures project. Of the algorithms that we tested, we found
that Strauss was fastest up to about 100 points, at which point Pippenger's was
fastest. You can see our initial benchmarks here
https://user-images.githubusercontent.com/2582071/32731185-12c0f108-c881-11e7-83c7-c2432b5fadf5.png
though this does not reflect some optimizations from Peter Dettmann in the last
week.
It was a happy coincidence that the Bulletproofs paper was published at nearly
the same time that we had working multi-point code to test with.
Finally, the Bulletproof verification process, as written in the paper, is a
recursive process which does not appear to be expressible as a single multiproduct,
and in fact it appears to require nearly twice as many multiplications as I claim
above. I want to draw attention to two optimizations in particular which made this
possible.
1. By expanding out the recursive process, one can see that the inner-product argument
(Protocol 1 in the paper) is actually one multiproduct: you hash each (L_i, R_i)
pair to obtain logarithmically many scalars, invert these, and then each scalar in
the final multiproduct is a product containing either the inverse or original of
each scalar.
Peter Dettmann found a way to reduce this to one scalar inversion, from which
every single scalar was obtainable from a single multiplication or squaring of a
previous result. I was able to implement this in a way that cached only log-many
previous results.
2. Next, line (62) of the Bulletproofs paper appears to require N multiplications
beyond the 2N multiplications already done in the recursive step. But since
these multiplications used the same basepoints that were used in the recursive
step, we could use the distributive property to combine them. This sounds
trivial but took a fair bit of care to ensure that all the right data was still
committed to at the right stage of proof verification.
Further Work
=========
There are still a few open issues I plan to help resolve in the coming month:
- Bulletproof aggregation is not compatible with Confidential Assets, where each
output has a unique asset tag associated with it. There are a couple possible
solutions to this but nothing public-ready.
- Bulletproofs, as described in the paper, work only when proving 2^n-many bits.
I believe there is a straightforward and verifier-efficient way to extend it
to support non-powers-of-2, but this requires some work to modify the proof in
the paper.
- Bulletproofs are actually much more general than rangeproofs. They can be used
to prove results of arbitrary arithmetic circuits, which is something we are
very interested in implementing.
[*] By "and so on", I mean that N bits require 2N + 2log_2(N) + 6 scalar multiplies.
Cheers
Andrew
--
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/20171204/42dfe0d1/attachment.sig>

2023-06-07 18:06:02

- 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:52

- reply

📅 Original date posted:2017-05-10
📝 Original message:On Tue, May 09, 2017 at 09:59:06PM -0400, Russell O'Connor via bitcoin-dev wrote:
> I'm a bit amateur at this sort of thing, but let me try to argue that this
> proposal is in fact horribly broken ;)
>
> Suppose Alice has some UTXO with some money Bob wants to steal. Grant me
> that the public key P0 protecting Alice's UTXO is public (say because the
> public key has been reused elsewhere).
>
> Bob going to spend Alice's UTXO by generating random values s0, k0 and R0
> := k0*G and thus creating a random signature for it, [R0, s0]. Now clearly
> this signature isn't going to be valid by itself because it is just random.
> Bob's goal will be to make a transaction with other inputs such that, while
> the individual signatures are not valid, the aggregated signature will be
> valid.
>
If you seed the randomization with every R value (which would come for free
if you used, say, the witness root) then Wagner's attack no longer applies.
The idea is that no aggregation occurs until a miner produces a block. You
have a bunch of independent Schnorr sigs (s_i, R_i). Then the _miner_ multiples
each s_i by H(witness root || index) or whatever, sums up the s_i's, and commits
the sum somewhere where it doesn't affect the root.
Verifiers then multiply each R_i by the same multiplying factors and are able
to do a batch verification of them.
Verifiers who have seen a signature before and cached it as valid can save
themselves a bit of time by subtracting H(witness root || index)*s_i from
the summed s-value and then skipping R_i in the above step. These are scalar
operations and are extremely cheap.
They can recognize the signature given only the transaction it signs and R_i,
which uniquely determine a valid signature.
I believe this is what Tadge was referring to when he mentioned a talk of mine.
It's roughly what I've had in mind whenever I talk about non-interactive Schnorr
aggregation.
Cheers
Andrew
--
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/20170510/ab8b75e7/attachment.sig>

2023-06-07 18:00:22

- 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:28:53

- reply

📅 Original date posted:2015-01-21
📝 Original message:I've read this and it looks A-OK to me.
Andrew
On Tue, Jan 20, 2015 at 07:35:49PM -0500, Pieter Wuille wrote:
> Hello everyone,
>
> We've been aware of the risk of depending on OpenSSL for consensus
> rules for a while, and were trying to get rid of this as part of BIP
> 62 (malleability protection), which was however postponed due to
> unforeseen complexities. The recent evens (see the thread titled
> "OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection."
> on this mailing list) have made it clear that the problem is very
> real, however, and I would prefer to have a fundamental solution for
> it sooner rather than later.
>
> I therefore propose a softfork to make non-DER signatures illegal
> (they've been non-standard since v0.8.0). A draft BIP text can be
> found on:
>
> https://gist.github.com/sipa/5d12c343746dad376c80
>
> The document includes motivation and specification. In addition, an
> implementation (including unit tests derived from the BIP text) can be
> found on:
>
> https://github.com/sipa/bitcoin/commit/bipstrictder
>
> Comments/criticisms are very welcome, but I'd prefer keeping the
> discussion here on the mailinglist (which is more accessible than on
> the gist).
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Andrew Poelstra
Mathematics Department, University of Texas at Austin
Email: apoelstra at wpsoftware.net
Web: http://www.wpsoftware.net/andrew
"If they had taught a class on how to be the kind of citizen Dick Cheney
worries about, I would have finished high school." --Edward Snowden
-------------- 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/20150121/c2345e35/attachment.sig>

2023-06-07 15:27:06

- 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>

2023-06-07 15:22:32

- reply

📅 Original date posted:2014-06-06
📝 Original message:On Sat, Jun 07, 2014 at 12:02:36AM +0200, Raúl Martínez wrote:
> I dont know if this attack is even possible, it came to my mind and I will
> try to explain it as good as possible.
>
> Some transacions keep unconfirmed forever and finally they are purged by
> Bitcoin nodes, mostly due to the lack of fees.
>
It's definitely possible. As Pieter says it is important to always reuse
inputs if you are "resending" a transaction. If you don't reuse inputs,
you are creating a new transaction and you should think of it as
spending twice as much money.
Like any information on the Internet, once a signed transaction leaves
your system there is no way to undo this. (Though of course, you can
respend the inputs to ensure that if ever your transaction resurfaces it
will not confirm.) This is true even if the transaction has low fees, is
nonstandard, or is otherwise inhibited from relaying.
I would go so far as to say that any UI which suggests otherwise (e.g.
offering a "cancel" feature which does not involve respending inputs or
that makes any guarantees about being effective) is dangerously broken.
--
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/20140606/20d1c22a/attachment.sig>