Nostr notes by Braydon Fuller [ARCHIVE]

📅 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-14 📝 Original message:On ...

2023-06-07T18:21:03Z

In reply to nevent1q…r409
_________________________

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