Nostr notes by Andrew Poelstra [ARCHIVE]

📅 Original date posted:2023-08-31 🗒️ Summary of this ...

2023-09-07T11:52:34Z

In reply to nevent1q…w7vp
_________________________

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

📅 Original date posted:2023-07-26 🗒️ Summary of this ...

2023-07-27T00:26:33Z

In reply to nevent1q…h9re
_________________________

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

📅 Original date posted:2021-03-16 📝 Original message:On ...

2023-06-07T18:30:57Z

In reply to nevent1q…mg5j
_________________________

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

📅 Original date posted:2021-03-15 📝 Original message:On ...

2023-06-07T18:30:55Z

In reply to nevent1q…3tvv
_________________________

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

📅 Original date posted:2021-03-16 📝 Original message:On ...

2023-06-07T18:30:54Z

In reply to nevent1q…fdgv
_________________________

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