Braydon Fuller [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-10-04 to 2020-09-09
💬 Posted a total of 16 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:00:14

- reply

📅 Original date posted:2020-05-08
📝 Original message:
On 5/5/20 5:31 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> Hi Antoine,
>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/headers,
>> that means you're asking 1PB/month of traffic to the backbone network. If
>> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
>> signal BIP 157, that's an increase of 100GB/month for each. Which is
>> consequent with regards to the estimated cost of 350GB/month for running
>> an actual public node
> One really dope thing about BIP 157+158, is that the protocol makes serving
> light clients now _stateless_, since the full node doesn't need to perform
> any unique work for a given client. As a result, the entire protocol could
> be served over something like HTTP, taking advantage of all the established
> CDNs and anycast serving infrastructure, which can reduce syncing time
> (less latency to
> fetch data) and also more widely distributed the load of light clients using
> the existing web infrastructure. Going further, with HTTP/2's server-push
> capabilities, those serving this data can still push out notifications for
> new headers, etc.
The statelessness of compact block filters does look useful. Bloom
filters for
blocks can be inefficient, during a scan with a BIP37 wallet, it's
necessary to
discard already received merkle blocks as the filter has been updated
and the
previous results may have missed transactions. Both bitcoinj [1] and
breadwallet-core [2] handle it using a similar method. The alternative of
synchronizing and alternating between requesting blocks and filter
updates leads
to slow scan times. With compact block filters, a separate wallet
process (from
the full node) can make adjustments necessary to what it needs to filter
without
having to communicate with the full node.
[1]:
https://github.com/bitcoinj/bitcoinj/blob/806afa04419ebdc3c15d5adf065979aa7303e7f6/core/src/main/java/org/bitcoinj/core/Peer.java#L1076-L1079
[2]:
https://github.com/breadwallet/breadwallet-core/blob/8eb05454df3e2d5cca248b4e24eeffa420c97e3a/bitcoin/BRPeer.c#L83-L85

2023-06-09 13:00:13

- reply

📅 Original date posted:2020-05-08
📝 Original message:
On 5/8/20 1:01 PM, Keagan McClelland wrote:
>> The RPC interface in Bitcoin Core, and others, is not great for this
>> because it exposes a lot of functionality that isn't necessary and
>> introduces risks.
> This is actually somewhat my point. If the RPC interface was good for this
> and *didn't* introduce risks, we could just use that and be done with it.
> But I'm finding there are many use cases that you want to have low cost
> ways to serve peer services to people whom you have given explicit
> permission, but they shouldn't have full ability to administrate the node.
>
> Perhaps I wasn't explicit in my previous note but what I mean is that there
> seems to be a demand for something *in between* a peer interface, and an
> owner interface. I have little opinion as to whether this belongs in core
> or not, I think there are much more experienced folks who can weight in on
> that, but without something like this, you cannot limit your exposure for
> serving something like bip157 filters without removing your own ability to
> make use of some of those same services.
An idea I was thinking about was having three ports for a full node:
1) Consensus bitcoin protocol. This is the existing peer-to-peer
protocol without additional services.
2) Wallet services protocol. Adds additional functionality for wallets.
For example bloom filtering, compact block filters, and potentially
output and address indexes for electrum-like support. It's nearly
identical to the consensus peer-to-peer protocol, supporting the same
wire format. As it's on another port, various middleware could be added
to support various authentication and transports.
3) Control interface. This is the existing JSON-RPC interface, without
all wallet related RPC methods.

2023-06-09 13:00:12

- reply

📅 Original date posted:2020-05-08
📝 Original message:
On 5/6/20 9:07 PM, Keagan McClelland wrote:
> I think that one of the solutions here is to have light clients choose
> their full node tethers explicitly. Even if you think it is unrealistic to
> have everyone run their own node (fwiw, I don’t), there is still a trust
> model where you can pick your trusted source.
>
> This way you could have many light clients working off of a family node,
> and the peer services could be limited to some sort of “authenticated”
> peers. Perhaps this is better accomplished over the RPC interface in Core,
> but the idea is to have some sort of peer service model between “full
> public” and “owner only”. This limits the amount of costs that can be
> properly externalized, without exposing risk of consensus capture by
> economically weighty institutions.
The RPC interface in Bitcoin Core, and others, is not great for this
because it exposes a lot of functionality that isn't necessary and
introduces risks. For example the `gettxoutsetinfo` can start a very
intensive CPU and disk I/O task. There are several others, for example:
`stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading
full raw blocks isn't very efficient with JSON. Electrum servers (e.g
electrs) for example read blocks from disk instead and use the RPC
interface to sync headers. Though, Electrum servers also have a risk of
DoS with addresses that have many transactions, see the `--txid-limit`
option [2].
[1]:
https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956
[2]:
https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289

2023-06-07 18:26:47

- reply

📅 Original date posted:2020-09-09
📝 Original message:Hi everyone:
We would like to share a paper and website for CVE-2018-17145 that was
found in mid-2018.
There was an easily exploitable uncontrolled memory resource consumption
denial-of-service vulnerability that existed in the peer-to-peer network
code of three implementations of Bitcoin and several alternative chains.
For more details please see:
https://invdos.net/
For the paper:
https://invdos.net/paper/CVE-2018-17145.pdf
Best,
Braydon Fuller

2023-06-07 18:24:28

- reply

📅 Original date posted:2020-05-08
📝 Original message:On 5/5/20 5:31 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> Hi Antoine,
>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/headers,
>> that means you're asking 1PB/month of traffic to the backbone network. If
>> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
>> signal BIP 157, that's an increase of 100GB/month for each. Which is
>> consequent with regards to the estimated cost of 350GB/month for running
>> an actual public node
> One really dope thing about BIP 157+158, is that the protocol makes serving
> light clients now _stateless_, since the full node doesn't need to perform
> any unique work for a given client. As a result, the entire protocol could
> be served over something like HTTP, taking advantage of all the established
> CDNs and anycast serving infrastructure, which can reduce syncing time
> (less latency to
> fetch data) and also more widely distributed the load of light clients using
> the existing web infrastructure. Going further, with HTTP/2's server-push
> capabilities, those serving this data can still push out notifications for
> new headers, etc.
The statelessness of compact block filters does look useful. Bloom
filters for
blocks can be inefficient, during a scan with a BIP37 wallet, it's
necessary to
discard already received merkle blocks as the filter has been updated
and the
previous results may have missed transactions. Both bitcoinj [1] and
breadwallet-core [2] handle it using a similar method. The alternative of
synchronizing and alternating between requesting blocks and filter
updates leads
to slow scan times. With compact block filters, a separate wallet
process (from
the full node) can make adjustments necessary to what it needs to filter
without
having to communicate with the full node.
[1]:
https://github.com/bitcoinj/bitcoinj/blob/806afa04419ebdc3c15d5adf065979aa7303e7f6/core/src/main/java/org/bitcoinj/core/Peer.java#L1076-L1079
[2]:
https://github.com/breadwallet/breadwallet-core/blob/8eb05454df3e2d5cca248b4e24eeffa420c97e3a/bitcoin/BRPeer.c#L83-L85

2023-06-07 18:24:24

- reply

📅 Original date posted:2020-05-08
📝 Original message:On 5/8/20 1:01 PM, Keagan McClelland wrote:
>> The RPC interface in Bitcoin Core, and others, is not great for this
>> because it exposes a lot of functionality that isn't necessary and
>> introduces risks.
> This is actually somewhat my point. If the RPC interface was good for this
> and *didn't* introduce risks, we could just use that and be done with it.
> But I'm finding there are many use cases that you want to have low cost
> ways to serve peer services to people whom you have given explicit
> permission, but they shouldn't have full ability to administrate the node.
>
> Perhaps I wasn't explicit in my previous note but what I mean is that there
> seems to be a demand for something *in between* a peer interface, and an
> owner interface. I have little opinion as to whether this belongs in core
> or not, I think there are much more experienced folks who can weight in on
> that, but without something like this, you cannot limit your exposure for
> serving something like bip157 filters without removing your own ability to
> make use of some of those same services.
An idea I was thinking about was having three ports for a full node:
1) Consensus bitcoin protocol. This is the existing peer-to-peer
protocol without additional services.
2) Wallet services protocol. Adds additional functionality for wallets.
For example bloom filtering, compact block filters, and potentially
output and address indexes for electrum-like support. It's nearly
identical to the consensus peer-to-peer protocol, supporting the same
wire format. As it's on another port, various middleware could be added
to support various authentication and transports.
3) Control interface. This is the existing JSON-RPC interface, without
all wallet related RPC methods.

2023-06-07 18:24:24

- reply

📅 Original date posted:2020-05-08
📝 Original message:On 5/6/20 9:07 PM, Keagan McClelland wrote:
> I think that one of the solutions here is to have light clients choose
> their full node tethers explicitly. Even if you think it is unrealistic to
> have everyone run their own node (fwiw, I don’t), there is still a trust
> model where you can pick your trusted source.
>
> This way you could have many light clients working off of a family node,
> and the peer services could be limited to some sort of “authenticated”
> peers. Perhaps this is better accomplished over the RPC interface in Core,
> but the idea is to have some sort of peer service model between “full
> public” and “owner only”. This limits the amount of costs that can be
> properly externalized, without exposing risk of consensus capture by
> economically weighty institutions.
The RPC interface in Bitcoin Core, and others, is not great for this
because it exposes a lot of functionality that isn't necessary and
introduces risks. For example the `gettxoutsetinfo` can start a very
intensive CPU and disk I/O task. There are several others, for example:
`stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading
full raw blocks isn't very efficient with JSON. Electrum servers (e.g
electrs) for example read blocks from disk instead and use the RPC
interface to sync headers. Though, Electrum servers also have a risk of
DoS with addresses that have many transactions, see the `--txid-limit`
option [2].
[1]:
https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956
[2]:
https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289

2023-06-07 18:21:05

- reply

📅 Original date posted:2019-10-14
📝 Original message:On 10/12/19 9:27 AM, Tier Nolan via bitcoin-dev wrote:
> [...]
>
> I think parallel downloading would be better than focusing on one peer
> initially. Otherwise, a dishonest peer can slowly send their headers to
> prevent moving to parallel mode.
>
> [...]
As implemented, there is a timeout for that loader peer based on the
amount of time it should take to request all the headers. The time
period is defined as a base time plus the number of expected headers
times an expected amount of time per header. For example, the timeout
would be 25 minutes with a base time of 15 minutes, 1 millisecond per
header and an expected 600000 headers.

2023-06-07 18:21:05

- reply

📅 Original date posted:2019-10-16
📝 Original message:On 10/12/19 1:46 PM, Tier Nolan via bitcoin-dev wrote:
> On Sat, Oct 12, 2019 at 6:56 PM Joachim Strömbergson <joachimstr at protonmail.com> wrote:
>> On different note, one of the problems that I haven't seen mentioned here
>> yet is the timewarp attack. It is relevant to some of the proposed
>> solutions. It should be possible, IIRC, for a malicious node to generate
>> much longer chain with superslow timestamp increase (~5 blocks in 1 second)
>> without increasing difficulty (i.e. staying at min. diff.). This could
>> produce chain that is ~2500 times longer than main chain without having
>> multiple branches.
>>
> [..]
>
> The timewarp bug can be fixed by a basic soft fork. You just need to limit
> the maximum difference between the timestamp for the first header in a
> period and the last header in the previous period.
Yeah, that makes sense as it corrects the off-by-one error. I think this
solution has been included in a draft proposal "The Great Consensus
Cleanup". It would need to be effective for not only the main chain but
also for any future forked chain.

2023-06-07 18:21:04

- reply

📅 Original date posted:2019-10-16
📝 Original message:On 10/15/19 8:50 AM, Joachim Strömbergson wrote:
>>>>> [...] to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). [...]
>>>>> In that case, it would take about 7 minutes of block time seconds for
>>>>> the next retarget period, every 2016 blocks, and the difficulty would
>>>>> adjust. The difficulty would adjust in that case as if 2 weeks of blocks
>>>>> had been mined in 7 minutes. For the difficulty to remain the same the
>>>>> time between blocks needs to be 10 minutes.
>>>>> This calculation does not apply under time warp attack. You can fake timestamps of all blocks except for those relevant to the retarget calculation. Those are only the first and the last block in the 2016 block window.
>> This must be in reference to the non-overlapping difficulty calculation
>> and off-by-one bug?
> Indeed.
>
Yeah, limiting the width of the chain would not be effective unless the
timewarp off-by-one bug is resolved — the height can be extended instead.
Rate limiting based on chainwork would slow down a timewarped low work
header chain. There would be a maximum rate at which the headers could
be sent. It would be around 32KB/s. It would take about a month to send
100GB.

2023-06-07 18:21:04

- reply

📅 Original date posted:2019-10-15
📝 Original message:On 10/15/19 12:20 AM, Joachim Strömbergson wrote:
>>> [...] to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). [...]
>> In that case, it would take about 7 minutes of block time seconds for
>> the next retarget period, every 2016 blocks, and the difficulty would
>> adjust. The difficulty would adjust in that case as if 2 weeks of blocks
>> had been mined in 7 minutes. For the difficulty to remain the same the
>> time between blocks needs to be 10 minutes.
> This calculation does not apply under time warp attack. You can fake timestamps of all blocks except for those relevant to the retarget calculation. Those are only the first and the last block in the 2016 block window.
This must be in reference to the non-overlapping difficulty calculation
and off-by-one bug?

2023-06-07 18:21:03

- reply

📅 Original date posted:2019-10-14
📝 Original message:On 10/12/19 10:56 AM, Joachim Strömbergson via bitcoin-dev wrote:
> [...] First you provide proof of your best block height via coinbase [...]
So I don't think you can use the height in the coinbase for that
purpose, as it's not possible to validate it without the previous
headers. That's common for more than just the height.
> [...] to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). [...]
In that case, it would take about 7 minutes of block time seconds for
the next retarget period, every 2016 blocks, and the difficulty would
adjust. The difficulty would adjust in that case as if 2 weeks of blocks
had been mined in 7 minutes. For the difficulty to remain the same the
time between blocks needs to be 10 minutes.

2023-06-07 18:21:02

- reply

📅 Original date posted:2019-10-10
📝 Original message:On 10/4/19 4:31 PM, Tier Nolan via bitcoin-dev wrote
> [..] At root, the requirement is that peers can prove their total chain POW. [...]
Indeed, it's currently necessary to receive all of the chain headers to
determine. It would be interesting to have a succinct chainwork proof
for all cases. Chainwork being a sum of the total proof-of-work in a
chain. Such proofs currently only require a few headers for common cases
and the other cases can be identified.
> In regard to your proposal, I think the key is to limit things by peer, rather than globally. [...]
Yeah, there should be enough width available for every active
connection, only one chain of headers is requested at a time per peer.
Peer based limiting is susceptible to Sybil attacks; A peer could
broadcast a few low-work header chains, reconnect and repeat ad nauseam.
The delay for the next set of headers is based on the chainwork of the
last received headers from the peer. The peer could change identity and
run into the same limit. The unrequested header rate is tracked per peer.
A header chain with more chainwork will be requested at a faster rate
than a header chain with less chainwork. The chainwork is compared to
the current fully validated chain. Honest peers with more chainwork will
have a time advantage over dishonest peers with less chainwork.
For example, let's assume a case that the initial chain of headers was
dishonest and with low chainwork. The initial block download retrieves
the header chain from a single loader peer first. Once recent time is
reached, header chains are downloaded from all outgoing peers. A single
honest peer will have an advantage over many dishonest peers. Thus, as
you have mentioned, there is a security assumption that there is at
least one connected honest node.

2023-06-07 18:21:01

- reply

📅 Original date posted:2019-10-11
📝 Original message:On 10/4/19 1:20 AM, David A. Harding wrote:
> On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev wrote:
>> This paper describes a solution [to DoS attacks] that does not
>> require enabling or maintaining checkpoints and provides improved security.
>> [...]
>> The paper is available at:
>> https://bcoin.io/papers/bitcoin-chain-expansion.pdf
> Hi Braydon,
>
> Thank you for researching this important issue. An alternative solution
> proposed some time ago (I believe originally by Gregory Maxwell) was a
> soft fork to raise the minimum difficulty. You can find discussion of
> it in various old IRC conversations[1,2] as well as in related changes
> to Bitcoin Core such as PR #9053 addining minimum chain work[3] and the
> assumed-valid change added in Bitcoin Core 0.14.0[4].
>
> [1] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html#l-121
> [2] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.log.html#l-57
> [3] https://github.com/bitcoin/bitcoin/pull/9053/commits/fd46136dfaf68a7046cf7b8693824d73ac6b1caf
> [4] https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
>
Okay, here is an overview of what I have found for the minimum
difficulty proposal:
It describes having a new consensus rule to not fork or accept headers
prior to, or below, a minimum difficulty once the best chain work is
achieved at release time of the software. This would be instead of the
rule to not fork before the last checkpoint, as checkpoints are removed.
It has an advantage to the existing checkpoint solution as it does not
require checkpoints to be enabled. This is not a surprise as the
proposal was to remove checkpoints entirely. It would increase the cost
of the attack without checkpoints. Long header chains would need to be
built using this minimum difficulty, instead of the current lowest
difficulty of the genesis block. The exact cost of that is not yet
calculated.
There are a few caveats with the approach mentioned; nodes are
vulnerable if the initial loader peer is the attacker, it could leave
minority hashpower without an ability to softfork away during a
contentious hardfork, and requires period consensus changes to continue
to maintain:
- Nodes are vulnerable during the initial sync when joining the
network until the minimum chainwork is achieved. This is possible if the
loader peer is the attacker. To mitigate this there would need to be a
minimum chainwork defined based on the current chainwork. However, such
could also be used to prevent nodes from joining the network as it's
rejecting rather that throttling.
- A contentious hardfork could leave a minority hashpower without an
ability to softfork away without agreeing on a hardfork. This was the
reason why the minimum difficulty was about 10 devices instead of 10,000.
- It's technically a consensus change each time the minimum difficulty
or best chainwork is updated. It is a similar consensus change as
maintaining the last checkpoint, as it's used to prevent forking prior
to the last checkpoint.
I think the solution proposed in the Bitcoin Chain Width Expansion paper
solves those issues by limiting chain width and throttling based on
chainwork, instead of rejecting blocks based on the minimum difficulty.

2023-06-07 18:21:01

- reply

📅 Original date posted:2019-10-03
📝 Original message:Hi everyone,
We would like to share a paper for broad discussion, it is titled
"Bitcoin Chain Width Expansion Denial-of-Service Attacks".
>From the abstract: The attacks leverage unprotected resources for a
denial-of-service by filling the disk and exhausting the CPU with
unnecessary header and block data. This forces the node to halt
operation. The attack difficulty ranges from difficult to easy. There
are currently limited guards for some of the attacks that require
checkpoints to be enabled. This paper describes a solution that does not
require enabling or maintaining checkpoints and provides improved security.
As the checkpoints in Bitcoin Core have not been maintained or updated
since mid 2014, this is especially relevant. Bitcoin Core implements
headers-first synchronization, since 2014, that provides the base for
the further improvements upon that design.
The paper is available at:
https://bcoin.io/papers/bitcoin-chain-expansion.pdf
The proposed solution has been implemented in Bcoin and is available at:
https://github.com/bcoin-org/bcoin/tree/chain-expansion
Best,
Braydon Fuller

2023-06-07 18:21:01

- reply

📅 Original date posted:2019-10-04
📝 Original message:On 10/4/19 1:20 AM, David A. Harding wrote:
> On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev wrote:
>> This paper describes a solution [to DoS attacks] that does not
>> require enabling or maintaining checkpoints and provides improved security.
>> [...]
>> The paper is available at:
>> https://bcoin.io/papers/bitcoin-chain-expansion.pdf
> [..] But I worry that the mechanisms could also be used to keep a node that
> synced to a long-but-lower-PoW chain on that false chain (or other false
> chain) indefinitely even if it had connections to honest peers that
> tried to tell it about the most-PoW chain.
Here is an example: An attacker eclipses a target node during the
initial block download; all of the target's outgoing peers are the
attacker. The attacker has a low work chain that is sent to the target.
The total chainwork for the low work chain is 0x09104210421039 at a
height of 593,975. The target is now in the state of a fully validated
low work dishonest chain. The target node then connects to an honest
peer and learns about the honest chain. The chainwork of the honest
chain is 0x085b67d9e07a751e53679d68 at a height of 593,975. The first
69,500 headers of the honest chain would have a delay, however the
remaining 52,4475 would not be delayed. Given a maximum of 5 seconds,
this would be a total delay of only 157 seconds.