đź“… 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
Braydon Fuller [ARCHIVE] /
npub1fx…xxtaa
2023-06-09 13:00:12
in reply to nevent1q…dlhw
Author Public Key
npub1fx2eyw7avet7dut0slazcehwvrrlhjp2u9jc9zd92l7nexpxeahs4xxtaaPublished at
2023-06-09 13:00:12Event JSON
{
"id": "9de9fc3474d5d800596b0f523713597ac2ef847eeb3fc2c1e24a44a03d0d0446",
"pubkey": "4995923bdd6657e6f16f87fa2c66ee60c7fbc82ae1658289a557fd3c9826cf6f",
"created_at": 1686315612,
"kind": 1,
"tags": [
[
"e",
"fe60513fd93e5b8aa19bf74b8481dfcc2b3f8faff34b68fd71fc053010ec09c9",
"",
"root"
],
[
"e",
"473d551a4a81ef4b977e31830d82e5d4aa1861ed811ee90a212a3e9573ee3511",
"",
"reply"
],
[
"p",
"4aa66c838f2cc55afbd46335fb2520507e2030601f773b28b96b76ec60a2f489"
]
],
"content": "📅 Original date posted:2020-05-08\n📝 Original message:\nOn 5/6/20 9:07 PM, Keagan McClelland wrote:\n\n\u003e I think that one of the solutions here is to have light clients choose\n\u003e their full node tethers explicitly. Even if you think it is unrealistic to\n\u003e have everyone run their own node (fwiw, I don’t), there is still a trust\n\u003e model where you can pick your trusted source.\n\u003e\n\u003e This way you could have many light clients working off of a family node,\n\u003e and the peer services could be limited to some sort of “authenticated”\n\u003e peers. Perhaps this is better accomplished over the RPC interface in Core,\n\u003e but the idea is to have some sort of peer service model between “full\n\u003e public” and “owner only”. This limits the amount of costs that can be\n\u003e properly externalized, without exposing risk of consensus capture by\n\u003e economically weighty institutions.\n\nThe RPC interface in Bitcoin Core, and others, is not great for this\nbecause it exposes a lot of functionality that isn't necessary and\nintroduces risks. For example the `gettxoutsetinfo` can start a very\nintensive CPU and disk I/O task. There are several others, for example:\n`stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading\nfull raw blocks isn't very efficient with JSON. Electrum servers (e.g\nelectrs) for example read blocks from disk instead and use the RPC\ninterface to sync headers. Though, Electrum servers also have a risk of\nDoS with addresses that have many transactions, see the `--txid-limit`\noption [2].\n\n[1]:\nhttps://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956\n[2]:\nhttps://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289",
"sig": "f008bbc838d2ee8a666facf92a0faea01c91ce5ce486d0c1f06c8229ec90150d31485a178fb0ceca877f8ce05817793780eaf754d3252ae0cf6ab193b1d36bb9"
}