📅 Original date posted:2013-07-23
📝 Original message:On Tuesday 23 July 2013 10:47:03 Peter Todd wrote:
> On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
> > One additional URL makes this pretty much perfect:
> > GET /rest/block-with-tx/TX-HASH
> >
> > Construction of the transaction-hash-to-block database is something the
> > full client's have to do anyway, so this query is no harder than the
> > others for them to supply; but suddenly makes it possible for an SPV
> > client to trace the providence of any transaction without needing to
> > maintain the entire chain.
> The REST API has nothing to do with SPV clients; it's similar to the RPC
> interface and won't be exposed to the network as a whole.
Yes; I know that. I'm saying that it would make it easier for SPV (and other
lightweight clients) for that matter.
> Increasing the resource usage by SPV clients on full nodes is undesirable;
I don't think that's thinking big enough. What I imagine is that making it
easier and easier to store a partial blockchain would result in lower demand
on full nodes.
I might run a client that has only fetched blocks that contain transactions
needed to verify my balances, right back to the genesis block. That will be
some small subset of the block chain and will take me very little resource to
maintain. I join the network and am my client is willing to verify based on
information I have, or supply (by REST or bitcoin protocol) blocks. Imagine
then that everyone with a wallet were doing this. The blockchain would be
distributed massively. Obviously the miners would still be keeping the entire
chain, but we'd have a lot more nodes in the network, each contributing a
little bit and so reducing the load on the full nodes.
> In any case UTXO data currently requires you to have full trust in
> whomever is providing you with it, and that situation will continue
> until UTXO commitments are implemented - if they are implemented.
Almost; because you can go and ask someone else the same question, it's pretty
easy to check if you're being lied to. Also, it's far easier to maintain a
headers-only block chain. When you fetch your relevant block subset, you can
easily see that they are real blocks in your headers-only blockchain; and so
it's pretty much impossible to lie to "give me the block containing
transaction X".
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nx…7wjrv
2023-06-07 15:04:59
in reply to nevent1q…uzz4
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 15:04:59Event JSON
{
"id": "7892e40d098dca2744bd43b10aa365d6715f9f7e0010e651d622cabb955a076f",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686150299,
"kind": 1,
"tags": [
[
"e",
"2548e3bbd5806f0a91f1440e5be19b1893f723d052860cba20b98f557d042316",
"",
"root"
],
[
"e",
"0e20374d874d670bf797897e48b1a35c6bff2cbd6f05073cd958e3a111f9d904",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-07-23\n📝 Original message:On Tuesday 23 July 2013 10:47:03 Peter Todd wrote:\n\u003e On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:\n\u003e \u003e One additional URL makes this pretty much perfect:\n\u003e \u003e GET /rest/block-with-tx/TX-HASH\n\u003e \u003e \n\u003e \u003e Construction of the transaction-hash-to-block database is something the\n\u003e \u003e full client's have to do anyway, so this query is no harder than the\n\u003e \u003e others for them to supply; but suddenly makes it possible for an SPV\n\u003e \u003e client to trace the providence of any transaction without needing to\n\u003e \u003e maintain the entire chain.\n\n\u003e The REST API has nothing to do with SPV clients; it's similar to the RPC\n\u003e interface and won't be exposed to the network as a whole.\n\nYes; I know that. I'm saying that it would make it easier for SPV (and other \nlightweight clients) for that matter.\n\n\u003e Increasing the resource usage by SPV clients on full nodes is undesirable;\n\nI don't think that's thinking big enough. What I imagine is that making it \neasier and easier to store a partial blockchain would result in lower demand \non full nodes.\n\nI might run a client that has only fetched blocks that contain transactions \nneeded to verify my balances, right back to the genesis block. That will be \nsome small subset of the block chain and will take me very little resource to \nmaintain. I join the network and am my client is willing to verify based on \ninformation I have, or supply (by REST or bitcoin protocol) blocks. Imagine \nthen that everyone with a wallet were doing this. The blockchain would be \ndistributed massively. Obviously the miners would still be keeping the entire \nchain, but we'd have a lot more nodes in the network, each contributing a \nlittle bit and so reducing the load on the full nodes.\n\n\u003e In any case UTXO data currently requires you to have full trust in\n\u003e whomever is providing you with it, and that situation will continue\n\u003e until UTXO commitments are implemented - if they are implemented.\n\nAlmost; because you can go and ask someone else the same question, it's pretty \neasy to check if you're being lied to. Also, it's far easier to maintain a \nheaders-only block chain. When you fetch your relevant block subset, you can \neasily see that they are real blocks in your headers-only blockchain; and so \nit's pretty much impossible to lie to \"give me the block containing \ntransaction X\".\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "9899cbcef797dd47cc45060def958f314529fe3e97c75fbc5659ed542101672979a68c92c181f125184466aa87d3709c4b2480cd605e38a9721f63a55ab45e49"
}