Nostr notes by Braydon Fuller [ARCHIVE]

📅 Original date posted:2020-05-08 📝 Original message: On ...

2023-06-09T13:00:12Z

In reply to nevent1q…dlhw
_________________________

📅 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

📅 Original date posted:2020-09-09 📝 Original message:Hi ...

2023-06-07T18:26:47Z

In reply to nevent1q…at8u
_________________________

📅 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

📅 Original date posted:2020-05-08 📝 Original message:On ...

2023-06-07T18:24:24Z

In reply to nevent1q…sqrs
_________________________

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

📅 Original date posted:2020-05-08 📝 Original message:On ...

2023-06-07T18:24:24Z

In reply to nevent1q…qff3
_________________________

📅 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

📅 Original date posted:2019-10-11 📝 Original message:On ...

2023-06-07T18:21:01Z

In reply to nevent1q…wdv8
_________________________

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

📅 Original date posted:2019-10-03 📝 Original message:Hi ...

2023-06-07T18:21:01Z

In reply to nevent1q…wlrw
_________________________

📅 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

📅 Original date posted:2019-10-04 📝 Original message:On ...

2023-06-07T18:21:01Z

In reply to nevent1q…yy4z
_________________________

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