[bitcoin-dev] Transcripts from Breaking Bitcoin 2019

[Bryan Bishop via bitcoin-dev]

Hi all,

The following are some notes I took during Breaking Bitcoin 2019, selected
for relevance. Any mistakes are most likely my own.

Carl Dong gave an excellent talk on guix as a replacement for the gitian
build system:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/bitcoin-build-system/
but really just watch his presentation:
https://www.youtube.com/watch?v=I2iShmUTEl8

Mempool analysis, client-side filtering, client updates
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/mempool-analysis-simulation/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/neutrino/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/p2p-encryption/

Some privacy and coinjoin talks:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/breaking-bitcoin-privacy/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/breaking-wasabi/

Hardware wallets:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/extracting-seeds-from-hardware-wallets/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/future-of-hardware-wallets/

Bitcoin upgrades:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/secure-protocols-bip-taproot/

p2pool analysis:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/security-attacks-decentralized-mining-pools/

Lightning network:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-routing-security/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-topological-analysis/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-security-panel/

Of possible interest (general, not really development focused):
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/defense-of-bitcoin/

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

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 49, Issue 8

[Emil Engler via bitcoin-dev]

But using the testnet means that you actually need to deal with resets. 
There were 2 resets in the past but the last was in 2011.


Am 09.06.19 um 16:55 schrieb Tim Menapace:

 >I don't get why the testnet shouldn't be >resetted just because there is
 >a (probably better) alternative for it. The >testnet is still a thing and
 >is also used.

Like Bryan said, lot of miners test here. E.g. new firmware versions, 
hardware prototypes and operation services. Difficulty will be on 
current levels in a short period of time.

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

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 49, Issue 8

[Tim Menapace via bitcoin-dev]

>I don't get why the testnet shouldn't be >resetted just because there is 
>a (probably better) alternative for it. The >testnet is still a thing and 
>is also used.

Like Bryan said, lot of miners test here. E.g. new firmware versions, hardware 
prototypes and operation services. Difficulty will be on current levels in a 
short period of time.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[David A. Harding via bitcoin-dev]

On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
> Matt Corallo  writes:
> > 2) wrt rule 4, I'd like to see a calculation of worst-case free
> > relay. I think we're already not in a great place, but maybe it's
> > worth it or maybe there is some other way to reduce this cost
> > (intuitively it looks like this proposal could make things very,
> > very, very bad).
> 
> I *think* you can currently create a tx at 1 sat/byte, have it
> propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
> times before your transaction gets mined.

Yes, the current incremental relay fee in Bitcoin Core is 0.1000
BTC/KvB.

> If that's true, I don't think this proposal makes it worse.

Here's a scenario that I think shows it being at least 20x worse.

Let's imagine that you create two transactions:

  tx0: A very small transaction (~100 vbytes) that's just 1-in, 1-out.
   At the minimum relay fee, this costs 0.0100 BTC

  tx1: A child of that transaction that's very large (~100,000 vbytes,
   or almost 400,000 bytes using special scripts that allow witness
   stuffing).  At the minimum relay fee, this costs 0.0010 BTC

Under the current rules, if an attacker wants to fee-bump tx0 by the
minimum incremental fee (a trivial amount, ~0.0100 BTC), the
attacker's replacement also needs to pay for the eviction of the huge
child tx1 by that same incremental fee (~0.0010).

Thus the replacement would cost the attacker a minimum of about
0.00100100 (~1 mBTC) for the original transactions and 0.00100100 for
the replacement (about 2 mBTC total).

The attacker could then spend another 1 mBTC re-attaching the child and
yet another 1 mBTC bumping again, incuring about a 2 mBTC cost per
replacement round.  At writing, 2 mBTC is about $14.00 USD---an amount
that's probably enough to deter most attacks at scale.

* * *

Under the new proposed rule 6, Mallory's replacement cost would be the
amount to get the small tx0 to near the top of the mempool (say
0.0010 BTC/KvB, so 0.0001 BTC total).  Because this would evict
the expensive child, it would actually reduce the original amount paid
by the attacker by 90% compared to the previous section's example where
using RBF increased the original costs by 100%.

The 0.1 mBTC cost of this attack is about $0.70 USD today for the
roughly the same data relay use as one round of the currently possible
attack.  In short, if I haven't misplaced a decimal point or made some
other mistake, I think the proposed rule 6 would result in approximately
a 95% reduction in the cost paid by an attacker for wasting 400,000
bytes of bandwidth per node (x60,000 nodes = 24 GB across all nodes, not
counting INV overhead).

Although the attacker might only get one replacement per block per
transaction pair out of this version of the attack, they could execute
the attack many times in parallel using different tranaction pairs.  If
this is combined with the treadmill leapfrogging Russell O'Connor
described elsewhere in this thread, the attack could possibly be
repeated multiple times per block per transaction pair at only slightly
increased cost (to pay the increasing next-block transaction fees).

> >> 3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty
> >> nasty DoS attack, but it may also be the case that is (a) not worse
> >> than other fundamental issues or (b) sufficiently expensive.
> 
> I thought we still meet rule 5 in practice since bitcoind will never
> even accept a tree of unconfirmed txs which is > 100 txs?  That would
> still stand, it's just that we'd still consider a replacement.

Although the BIP125 limit is 100, Bitcoin Core's current default is 25.[1]
(When RBF was implemented in Bitcoin Core, transaction ancestry was only
tracked for purposes of ensuring valid transaction ordering within
blocks; later when CPFP was implemented, ancestry was additionally used
to calculate each transaction's package fee---the value of it and all
its unconfirmed ancestors.  This requires more computation to update
the mempool metadata when the ancestry graph changes.)

Again, I'd be thinking here of something similar to O'Connor's
treadmilling attack where replacements can push each other out of the
top mempool and so create enough churn for a CPU exhaustion attack.

> >>  Obviously there is also a ton more client-side knowledge required
> >>  and complexity to RBF decisions here than other previous, more
> >>  narrowly-targeted proposals.
> I'd say from the lightning side it's as simple as a normal RBF policy
> until you get within a few blocks of a deadline, then you increase the
> fees until it's well within reach of the next block.

It's already hard for wallet software to determine whether or not its
transactions have successfully been relayed.  This proposal requires LN
wallets not only be able to guess where the next-block feerate boundary
is in other nodes' individual mempools (now and in the future for the
time it takes

[bitcoin-dev] WORKVERIFY: uncensorable contracts hedging biggest risk of mining without 3rd party or oracle

[Tamas Blummer via bitcoin-dev]

In an earlier post [1] I suggested an approach to create native Bitcoin 
contracts that reduce mining's income volatility and received very helpful 
comments on implementation from Pieter Wuille [2] and Natanael [3]

After processing those comments I instead suggest the following restricted 
interpretation of nSequence and a new opcode WORKVERIFY that in combination is 
easier to implement and reason about as it follows the implementation pattern 
of CHECKSEQUENCEVERIFY[5]

Accumulated work on the blockchain is strictly increasing, therefore 
transaction eligibility rule with a >= condition on it would need no 
re-evaluation for descendant blocks, in mempool or at re-org, since additional 
blocks or re-org can only increase the accumulated work. Accumulated work is 
just like time, it is actually an alternate measure of time through 
computation[6], therefore analogous to MTP based restriction implemented with 
BIP68 [4].

=== (the implementation proposal) ===

(needs soft fork for two reasons, activation logic tbd.)

I. Stricter interpretation of nSequence to optionally refer accumulated work:

Only if bit 31 AND bit 30 is set in nSequence can the transaction be included 
into any block. This is a restricting a rule of BIP68 [4] that only required 
bit 31 to be set for unrestricted inclusion into blocks. Otherwise nSequence 
refers to accumulated work (see encoding later) and it is only viable to 
include the transaction into a block if the block has >= work accumulated. This 
would define the meaning of one additional bit in nSequence, but leave all 
other freedom of later improvement left by BIP68.

II. New WORKVERIFY opcode redefining a NOPx in transaction script as:

Terminate script with false for any reason described in BIP112 or if bit 31 is 
set but bit 30 is not set and 256 bit unsigned integer on stack is higher than 
(nSequence &0x)>> 6 * 2^((nSequence & 0x3f) + 84)

=== (end proposal) ===

Notes on the work encoding:

Total accumulated work as of now is > 2^90 and if we assume that mining 
capacity keeps increasing with Moore’s law (double every year) for the next 50 
years, then it could sum up to 2^140. We have much less bits available in 
nSequence therefore we have to encode accumulated work in a floating point 
number with sufficient precision.

The work accumulated during the current difficulty adjustment cycle is > 2016 * 
2^74 which is > 2^84. It is rather unlikely that accumulated work in a 
difficulty adjustment period drops below 2^80 ever again in future which means 
we need not be more precise than  2^80/2^90 or 2^-10 to allow for contracts 
that reference increment until the next adjustment. Therefore a mantissa of 10 
bits should be sufficient. Using 6 bits of exponent and an offset of 2^84 we 
can express the range of [2^84, 2^148) that should be sufficient now and for 
foreseeable future. Please let me know if the approach is not optimal or future 
proof in your opinion.

Why, should we build this into Bitcoin ?

The most influential risk factor in miners' investment decision is the 
anticipated change of difficulty over the time horizon of the mining 
equipment's expected lifetime. Their investments secure the network. The 
ability to create contracts that reduce income volatility would lead to 
additional investment into mining.

A native Bitcoin contract is far superior to alternatives that could be offered 
on traditional markets as:

a native Bitcoin contract would be:
- uncensorable: It requires only the agreement to terms between those 
financially involved
- fully collaterized: no counterparty risk which means Miner could buy hedging 
contracts from any unkown and un-trusted actor that is able to commit collateral
- no oracle is needed
- no disagreement on the settlement
- publicly observable: allow to observe market opinion on future difficulty
- the length of the contract could match miner's investment horizon extending 
over several difficulty adjustments.

Why not on a side-chain ?

Work is fundamental and intrinsic to the base layer. A contract that reduces 
earnings volatility helps to attract more capital for mining and therefore 
increase security on the base layer.

How would this be used?

Miner and Speculator sign a transaction that has an nLockTime of S in the 
future. This gives both parties the option to alternatively spend committed 
output in case the other would not follow through and publish committing the 
collateral until S.

Speculators contribution to collateral is higher than that of the Miner. 
Miner’s collateral is the premium for the insurance provided by Speculator.

The single output of the transaction has following script:

IF
 CHECKLOCKTIMEVERIFY DROP
 CHECKSIGVERIFY
ELSE
 WORKVERIFY DROP
 CHECKSIGVERIFY
ENDIF

This allows the speculator to take back its collateral plus the option premium 
after the maturity time point, which would however only be possible if it was 
not taken earlier by Miner as suffici

Re: [bitcoin-dev] testnet4

[Emil Engler via bitcoin-dev]

I don't get why the testnet shouldn't be resetted just because there is 
a (probably better) alternative for it. The testnet is still a thing and 
is also used.


Am 08.06.19 um 16:21 schrieb Bryan Bishop:

Be greeted Emil,

On Sat, Jun 8, 2019 at 9:21 AM Emil Engler via bitcoin-dev 
> wrote:


Hello, I tried myself with some Bitcoin development. For this I used of
course the Bitcoin testnet. However it took me one hour to sync the
blockchain with around 1538358 blocks. In my opinion that is too much
for a testnet. Especially the blockchain size with around 26GB is so
much. Would it be possible to reset the testnet with a new genesis
block
? And if so, can we setup a fixed cycle for resetting the testnet (For
example every second 1st of January) ?


At the moment, I somewhat doubt this is likely to happen. Signet 
provides an alternative for configuring multiple separate private and 
public testing networks. If you would like to get involved, check out 
the recent discussion on the topic recorded here:

http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/

- Bryan
http://heybryan.org/

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

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Russell O'Connor via bitcoin-dev]

On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell  wrote:

> "Russell O'Connor"  writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> The new "emergency RBF" rule:
> >>
> >>  6. If the original transaction was not in the first 4,000,000 weight
> >> units of the fee-ordered mempool and the replacement transaction is,
> >> rules 3, 4 and 5 do not apply.
> >>
> >> This means:
> >>
> >> 3. This proposal does not open any significant new ability to RBF spam,
> >>since it can (usually) only be used once.  IIUC bitcoind won't
> >>accept more that 100 descendents of an unconfirmed tx anyway.
> >>
> >
> > Is it not possible for Alice to grief Bob's node by alternating RBFing
> two
> > transactions, each one placing itself at the bottom of Bob's top
> 4,000,000
> > weight mempool which pushes the other one below the top 4,000,000 weight,
> > and then repeating with the other transaction?  It might be possible to
> > amend this proposal to partially mitigate this.
>
> Good point.  This will cost Alice approximately one tx every block, but
> that may still be annoying.  My intuition says it's hard to play these
> games across swathes of non-direct peers, since mempools are in constant
> flux and propagation is a bit random.
>
> What mitigations were you thinking?
>

For example,  "If the original transaction was not in the first 4,000,000
weight units of the fee-ordered mempool and the replacement transaction is
in the first 2,000,000 weight units" might adequately address the issue.
There are probably other ways as well.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Rusty Russell via bitcoin-dev]

Matt Corallo  writes:
> I think this needs significantly improved motivation/description. A few areas 
> I'd like to see calculated out:
>
> 1) wrt rule 3, for this to be 
> obviously-incentive-compatible-for-the-next-miner, I'd think no evicted 
> transactions would be allowed to be in the next block range. This would 
> probably require some significant additional tracking in today's mempool 
> logic.

This is a good question, which is why I really wanted to look into the
implementation details.  There are some approximations possible wrt. pre-
and post- tx bundle feerate, but they have to be examined closely.

> 2) wrt rule 4, I'd like to see a calculation of worst-case free relay. I 
> think we're already not in a great place, but maybe it's worth it or maybe 
> there is some other way to reduce this cost (intuitively it looks like this 
> proposal could make things very, very, very bad).

I *think* you can currently create a tx at 1 sat/byte, have it
propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
times before your transaction gets mined.

If that's true, I don't think this proposal makes it worse.

>> 3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty nasty DoS 
>> attack, but it may also be the case that is (a) not worse than other 
>> fundamental issues or (b) sufficiently expensive.

I thought we still meet rule 5 in practice since bitcoind will never
even accept a tree of unconfirmed txs which is > 100 txs?  That would
still stand, it's just that we'd still consider a replacement.

> 4) As I've indicated before, I'm generaly not a fan of such vague
> protections for time-critical transactions such as payment channel
> punishment transactions.

The bitcoin network offers no propagation guarantees; it's all best
effort anyway.  This makes it no worse, and we can tunnel txs through
the lightning network if we have to.

> At a high-level, in this context your counterparty's transactions (not to 
> mention every other transaction in everyone's mempool) are still involved in 
> the decision about whether to accept an RBF, in contrast to previous 
> proposals, which makes it much harder to reason about. As a specific example, 
> if an attacker exploits mempool policy differences they may cause your 
> concept of "top 4M weight" to be bogus for a subeset of nodes, causing 
> propogation to be limited.

If miners have a conflicting tx in the top 4MSipa, you don't have a
problem.  So an attacker needs to limit propagation in a way which
isolates the miners from either the new tx or the conflicting one, which
is much harder.

> Obviously there is also a ton more client-side knowledge required and 
> complexity to RBF decisions here than other previous, more narrowly-targeted 
> proposals.

Define client-side here?

I'd say from the lightning side it's as simple as a normal RBF policy
until you get within a few blocks of a deadline, then you increase the
fees until it's well within reach of the next block.  You can even
approximate this by looking at fees on the previous block, with some
care for outliers.

> (I don't think this one use-case being not optimal should prevent such a 
> proposal, i agree it's quite nice for some other cases).

I like that it's conceptually simple and inventive-robust, and doesn't
really rely on bitcoind's internal policy mechanics of RBF.

I think in the longer term we're going to need other mechanisms for
restricting abusive propagation anyway, but that's a bit out-of-scope.

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

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Rusty Russell via bitcoin-dev]

"Russell O'Connor"  writes:
> Hi Rusty,
>
> On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The new "emergency RBF" rule:
>>
>>  6. If the original transaction was not in the first 4,000,000 weight
>> units of the fee-ordered mempool and the replacement transaction is,
>> rules 3, 4 and 5 do not apply.
>>
>> This means:
>>
>> 3. This proposal does not open any significant new ability to RBF spam,
>>since it can (usually) only be used once.  IIUC bitcoind won't
>>accept more that 100 descendents of an unconfirmed tx anyway.
>>
>
> Is it not possible for Alice to grief Bob's node by alternating RBFing two
> transactions, each one placing itself at the bottom of Bob's top 4,000,000
> weight mempool which pushes the other one below the top 4,000,000 weight,
> and then repeating with the other transaction?  It might be possible to
> amend this proposal to partially mitigate this.

Good point.  This will cost Alice approximately one tx every block, but
that may still be annoying.  My intuition says it's hard to play these
games across swathes of non-direct peers, since mempools are in constant
flux and propagation is a bit random.

What mitigations were you thinking?

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