Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Anthony Towns via bitcoin-dev]

On Tue, Oct 11, 2022 at 04:18:10PM +, Pieter Wuille via bitcoin-dev wrote:
> On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev 
>  wrote:
> > Thanks for the fast answer! It seems I missed the link to the PR, sorry for 
> > the
> > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > (https://github.com/bitcoin/bitcoin/pull/25353).
> It is not clear to me why you believe the merging of this particular pull 
> request poses an immediate risk to you.

Did you see the rest of Dario's reply, bottom-posted after the quoted
text? Namely:

On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via bitcoin-dev 
wrote:
> The "activation" of full-RBF after deployment works in a pretty interesting
> way:
> 
> 1. If no miner is running full-RBF or there aren't easily accessible
> connected components of nodes running full-RBF connected to the miners, then
> full-RBF is mostly ineffective since replacements aren't relayed and/or mined.
> 2. There's a middle ground where *some* connected components of full-RBF
>nodes can relay and mine replacements, where some full-RBF nodes will be
>able to replace via full-RBF and some won't (depending on their peers).
> 3. With high enough adoption, the relay graph has enough density of full-RBF
>nodes that almost all full-RBF nodes can replace transactions via
>full-RBF.
> 
> While there have been forks of Bitcoin Core (like Bitcoin Knots) running
> full-RBF for a while, today most nodes (by far) are running Bitcoin Core.
> So,
> Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to
> be
> picked up by most node operators. Making the flag opt-out (ie. on by
> default)
> would make it easier still. We are dealing with a gradient going from hard
> enough that we are still in 1, to easy enough that we get to 3.
> 
> The question then is whether an opt-in flag for full-RBF will have enough
> adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> objective of allowing nodes participating in multi-party funding protocols
> to assume that they can rely on full-RBF. If it is, then zero-conf 
> applications
> will be at severe risk (per the logic in the initial email).

That logic seems reasonably sound to me:

 - if adding the option does nothing, then there's no point adding it,
   and no harm in restricting it to test nets only

 - if adding the option does do something, then businesses using zero-conf
   need to react immediately, or will go from approximately zero risk of
   losing funds, to substantial risk

(I guess having the option today may allow you to manually switch your
node over to supporting fullrbf in future when the majority of the network
supports it, without needing to do an additional upgrade in the meantime;
but that seems like a pretty weak benefit)

Cheers,
aj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MuSig2 BIP

[Jonas Nick via bitcoin-dev]

It is still true that cryptography is hard, unfortunately. Yannick Seurin, Tim
Ruffing, Elliott Jin, and I discovered an attack against the latest version of
BIP MuSig2 in the case that a signer's individual key A = a*G is tweaked before
giving it as input to key aggregation.

In more detail, a signer may be vulnerable if _all_ of the following conditions
are true:

1. The signer supports signing with a tweaked individual key (as provided to
   key aggregation) and the tweak is known to the attacker (e.g., as in BIP 32
   unhardened derivation).
2. The signer's public key appears at least two times with different tweaks in
   the set of public keys that are aggregated. This would, for example, be the
   case if a signer with public key A=a*G creates partial signatures for an
   aggregate key corresponding to public key set {A, A+t*G} where t is some
   tweak. Note that an attacker could make this condition true by using the key
   B = A+t*G after having seen A.
3. The signer uses "concurrent signing", i.e., the signer stores secnonces for
   multiple signing sessions.
4. The secret key provided to the Sign algorithm is not yet fully determined 
when the
   NonceGen algorithm is called. This would, for example, be the case if the
   attacker, after having seen the nonce of the signer, can influence whether a
   or a+t will be provided as a secret key to Sign.

In this scenario, an attacker may forge a signature for any message and any
aggregate public key that contains the signer's individual public key A (with
any attacker-chosen tweak). In particular, the attacker may forge a signature
for any message and the public key A itself.

Condition 4 should only apply in relatively rare cases unless the signer is
tricked into such a situation.

Fix:
Note that if the optional secret key argument is provided to the NonceGen
algorithm and matches the secret key provided to the Sign algorithm, then
Condition 4 will not hold. Thus, one definite fix is to make the secret key
argument to the NonceGen algorithm mandatory. We are investigating other options
and will follow up shortly with a concrete fix of the BIP draft.

This discovery does not invalidate the security proof of the scheme as presented
in the MuSig2 paper because the security model in the paper does not support
tweaking a signer's key.

If you've implemented the BIP draft in your library or are already using it in
production don't hesitate to reach out to clarify the implications of this
discovery.

Tim Ruffing, Elliott Jin, Jonas Nick
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Pieter Wuille via bitcoin-dev]

On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev 
 wrote:


> Hello David,
> 
> Thanks for the fast answer! It seems I missed the link to the PR, sorry for 
> the
> confusion. I'm referring to the opt-in flag for full-RBF from #25353
> (https://github.com/bitcoin/bitcoin/pull/25353).

Hello Dario,

It is not clear to me why you believe the merging of this particular pull 
request poses an immediate risk to you.

As explained by others, it's only a configuration option that is default off, 
and the possibility of running rull-RBF policy nodes on the network have been 
trivial for anyone who wanted to for a long time on the network.

I don't want to sound dismissive of your concerns, but at this point I'm not 
convinced you're actually aware of what this PR does and doesn't do.

Cheers,

-- 
Pieter

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Validity Rollups on Bitcoin

[John Light via bitcoin-dev]

Hi all,

Today I am publishing "Validity Rollups on Bitcoin", a report I produced as 
part of the Human Rights Foundation's ZK-Rollup Research Fellowship.

Here's the preface:

> Ever since Satoshi Nakamoto first publicly announced bitcoin, its supporters, 
> critics, and skeptics alike have questioned how the protocol would scale as 
> usage increases over time. This question is more important than ever today, 
> as blocks are increasingly full or close to full of transactions. So-called 
> "Layer 2" (L2) protocols such as the Lightning Network have been deployed to 
> take some transaction volume "offchain" but even Lightning needs to use 
> _some_ bitcoin block space. It's clear that as bitcoin is adopted by more and 
> more of the world's population (human and machine alike!) more block space 
> will be needed. Another thread of inquiry concerns whether bitcoin's limited 
> scripting capabilities help or hinder its value as electronic cash. 
> Researchers and inventors have shown that the electronic cash transactions 
> first made possible by bitcoin could be given new form by improving 
> transaction privacy, supporting new types of smart contracts, and even 
> creating entirely new blockchain-based assets.
> 
> One of the results of the decade-plus research into scaling and expanding the 
> capabilities of blockchains such as bitcoin is the invention of the validity 
> rollup. Given the observed benefits that validity rollups have for the 
> blockchains that have already implemented them, attention now turns to the 
> question of whether they would be beneficial for bitcoin and existing bitcoin 
> L2 protocols such as Lightning, too. We explore this question by examining 
> validity rollups from several angles, including their history, how they work 
> on a technical level, how they could be built on bitcoin, and what the 
> benefits, costs, and risks of building them on bitcoin might be. We conclude 
> that validity rollups have the potential to improve the scalability, privacy, 
> and programmability of bitcoin without sacrificing bitcoin's core values or 
> functionality as a peer-to-peer electronic cash system. Given the "trustless" 
> nature of validity rollups as cryptographically-secured extensions of their 
> parent chain, and given bitcoin's status as the most secure settlement layer, 
> one could even say these protocols are a _perfect match_ for one another.

You can find the full report here:

https://bitcoinrollups.org

Happy to receive any comments and answer any questions the bitcoin dev 
community may have about the report!

Best regards,
John Light
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

[Greg Sanders via bitcoin-dev]

Propagation of these kinds of transactions will be hampered until  becomes 10%+ of the network or so, like any other policy
relaxation.

On Tue, Oct 11, 2022 at 9:08 AM KING JAMES HRMH 
wrote:

> I am reading between the lines, wouldn't that mean an older client like
> v0.18 may not be able to receive a transaction from a newer client if it
> has to validate 85 non-witness serialized bytes? If so we should not
> concern but retain the backward compatibility especially since this was for
> a vulnerability? I have not checked to code to see what it does.
>
> KING JAMES HRMH
>
> Get Outlook for Android 
> --
> *From:* bitcoin-dev  on
> behalf of Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Tuesday, October 11, 2022 11:50:07 PM
> *To:* Bitcoin Dev 
> *Subject:* [bitcoin-dev] Relaxing minimum non-witness transaction size
> policy restriction
>
> Hello fellow Bitcoiners,
>
> After looking at some fairly exotic possible transaction types, I ran into
> the current policy limit requiring transactions to be 85 non-witness
> serialized bytes. This was introduced as a covert fix to policy fix
> for CVE-2017-12842. Later the real motivation was revealed, but the
> "reasonable" constant chosen was not.
>
> I'd like to propose relaxing this to effectively the value BlueMatt
> proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
> allow a single input, single output transaction with 4 bytes of OP_RETURN
> padding, rather than padding out 21 bytes to get to p2wpkh size.
>
> The alternative would be to also allow anything below 64 non-witness
> bytes, but this seems fraught with footguns for a few bytes gain.
>
> The PR is here with more relevant background and alternatives included in
> the thread:
> https://github.com/bitcoin/bitcoin/pull/26265
>
> Please let us know if there's a fundamental issue with this approach, or
> any other feedback.
>
> Best,
> Greg
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Minor DoS vulnerability in BIP144 lack of tx witness data size limit

[Greg Sanders via bitcoin-dev]

There are a number of issues with adding arbitrary size restrictions to
consensus(I personally think it's additional complexity for negative gain),
but most of all this may resolve in burned coins.

On Tue, Oct 11, 2022 at 6:22 AM Loki Verloren via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> The recent 998 of 999 multisig segwit transaction highlights a problem
> with BIP144. As the solution applied for btcd shows, effectively a single
> transaction witness can be the same as the maximum block size.
>
> 11000 bytes may not be so unreasonable but now there is a special case
> with a block over 33k worth of witness data.
>
> A concrete limit should be set on the maximum size of a transaction
> witness, and this should be discussed in a more general sense about total
> transaction sizes.
>
> In the absence of a specification, it becomes impossible to properly
> implement and the status quo devolves to the actual implementation in the
> bitcoin core repository code.
>
> I think the weight calculation should escalate exponentially to discourage
> putting transactions like this on the chain. The price was equivalent to
> about $5 to do this.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

[Greg Sanders via bitcoin-dev]

Hello fellow Bitcoiners,

After looking at some fairly exotic possible transaction types, I ran into
the current policy limit requiring transactions to be 85 non-witness
serialized bytes. This was introduced as a covert fix to policy fix
for CVE-2017-12842. Later the real motivation was revealed, but the
"reasonable" constant chosen was not.

I'd like to propose relaxing this to effectively the value BlueMatt
proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
allow a single input, single output transaction with 4 bytes of OP_RETURN
padding, rather than padding out 21 bytes to get to p2wpkh size.

The alternative would be to also allow anything below 64 non-witness bytes,
but this seems fraught with footguns for a few bytes gain.

The PR is here with more relevant background and alternatives included in
the thread:
https://github.com/bitcoin/bitcoin/pull/26265

Please let us know if there's a fundamental issue with this approach, or
any other feedback.

Best,
Greg
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Minor DoS vulnerability in BIP144 lack of tx witness data size limit

[Loki Verloren via bitcoin-dev]

The recent 998 of 999 multisig segwit transaction highlights a problem with 
BIP144. As the solution applied for btcd shows, effectively a single 
transaction witness can be the same as the maximum block size.
11000 bytes may not be so unreasonable but now there is a special case with a 
block over 33k worth of witness data.

A concrete limit should be set on the maximum size of a transaction witness, 
and this should be discussed in a more general sense about total transaction 
sizes.

In the absence of a specification, it becomes impossible to properly implement 
and the status quo devolves to the actual implementation in the bitcoin core 
repository code.

I think the weight calculation should escalate exponentially to discourage 
putting transactions like this on the chain. The price was equivalent to about 
$5 to do this.

publickey - loki@cybriq.systems - 0x7BC3C653.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Silent Payment v4 (coinjoin support added)

[woltx via bitcoin-dev]

Silent Payment v4 (coinjoin support added)

Changes:

. Silent payments now use all inputs to create transactions. Previously, they 
only used the first input. This change increases privacy and makes silent 
payments compatible with coinjoin.

. `getspaddress` RPC renamed to `getsilentaddress` for clarity

. Added support for silent payment in PSBT via `walletcreatefundedpsbt` RPC.

. Added a new index scheme (which stores the sum of input public keys for each 
transaction). The previous index `bitcoin/signet/indexes/silentpaymentindex` 
should be removed as it is no longer compatible with this new version.

For reviewers:

Now, silent payments use the scheme `hash(i1*X + i2*X + i3*X + ...)*G + X == 
hash(x*(I1+I2+I3+...))*G + X`, as described here: 
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs

As inputs can be Taproot, this introduced a new issue as 
`bitcoin-core/secp256k1` does not support x-only public key sum (perhaps due to 
missing prefix byte).

I opened a new PR (#1143) to add a function to convert from x-only to 
compressed public key with even y. This is the solution being used by the 
current silent payment implementation.
Tutorial updated: https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev