Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-07 🗒️ Summary of this message: A lightweight ...
📅 Original date posted:2011-07-07
🗒️ Summary of this message: A lightweight client needs to calculate the balance of an arbitrary address without requiring the whole blockchain. A filter-by-address could help.
📝 Original message:On Thursday 07 July 2011 17:44:48 Mike Hearn wrote:
> > What I want to be able to do though is calculate a balance for an
> > aribtrary address. Not every address; just the particular ones that
> > the client is interested in. It's complete overkill to require the
> > whole block chain just to calculate the balance of a few addresses.
>
> But what is that for? You said it's for a lightweight client to do
> that when it receives a transaction, to verify that all the
> dependencies are in blocks recursively. But why?
There is no way for a client to know in advance whether any broadcast
transaction contains a send to an address in its wallet. So every incoming
transaction has to be examined.
Then, there is no way to know if while you were offline any of the
transactions in the blocks you missed contained transactions for an address
in your wallet.
Also, a feature I am interested in supporting is a split wallet -- where the
private key is held elsewhere. I'd still want to be able to report the
current balance in a particular address though. That address can be added
at any time.
Also, I would like to make some blockexplorer-like facilities available to
lightweight clients.
> > Not entirely. If I ask for "the block that contains transaction with
> > hash 12345678abcd..." then when I get that full block, I can verify
> > the merkle tree myself.
>
> Well, it's more efficient to just verify the merkle branch. But yes.
We're only talking about one verifying one (or minimal numbers of) blocks;
"efficient" isn't really going to matter much in that context. Also, if
we're talking about a situation where we don't necessarily trust the remote,
we've got to verify the whole block, not just the one transaction we're
interested in, since we told the remote which one we were interested in when
we requested it.
> > I'm not entirely sure I see how a filter helps. If I've been offline
> > for ten minutes then I need all the transactions pending in the last
> > ten minutes. No amount of filtering makes that list any smaller.
>
> Why do you need all of them? You just care about the ones sending
> coins to you, surely?
Is the filter going to be filter-by-address then? I misunderstood in that
case, I thought you were talking about filter-by-hash, which obviously tells
you nothing about the contents of the transaction.
> > That would be fine. My reason for suggesting using getblocks was that
> > it didn't introduce a new command.
>
> IMHO it's fine to introduce new commands. They'll just be ignored by
> old clients in any event.
That's good to know. I'm trying to be circumspect in what my client does; I
want to be 100% compatible, which means if I need a new feature, it's got to
be in the official client first.
I accept that this is all big talk, and there are plenty of people who start
new clients and then give up; which might still happen to me.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Published at
2023-06-07 02:03:28Event JSON
{
"id": "07753afcd15dc1d1078294fc312de31238d295e871e5975f404e99d3fab736b1",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686103408,
"kind": 1,
"tags": [
[
"e",
"9937cd991e90b8eac747cbbc95f665ee02332070c215333b4ec526b53cec3cee",
"",
"root"
],
[
"e",
"cb3d37d2e169f3c25fdde1cb258452510c8b07a93a2fd6f9d61aa9cd15b97084",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2011-07-07\n🗒️ Summary of this message: A lightweight client needs to calculate the balance of an arbitrary address without requiring the whole blockchain. A filter-by-address could help.\n📝 Original message:On Thursday 07 July 2011 17:44:48 Mike Hearn wrote:\n\u003e \u003e What I want to be able to do though is calculate a balance for an\n\u003e \u003e aribtrary address. Not every address; just the particular ones that\n\u003e \u003e the client is interested in. It's complete overkill to require the\n\u003e \u003e whole block chain just to calculate the balance of a few addresses.\n\u003e \n\u003e But what is that for? You said it's for a lightweight client to do\n\u003e that when it receives a transaction, to verify that all the\n\u003e dependencies are in blocks recursively. But why?\n\nThere is no way for a client to know in advance whether any broadcast \ntransaction contains a send to an address in its wallet. So every incoming \ntransaction has to be examined.\n\nThen, there is no way to know if while you were offline any of the \ntransactions in the blocks you missed contained transactions for an address \nin your wallet.\n\nAlso, a feature I am interested in supporting is a split wallet -- where the \nprivate key is held elsewhere. I'd still want to be able to report the \ncurrent balance in a particular address though. That address can be added \nat any time.\n\nAlso, I would like to make some blockexplorer-like facilities available to \nlightweight clients.\n\n\u003e \u003e Not entirely. If I ask for \"the block that contains transaction with\n\u003e \u003e hash 12345678abcd...\" then when I get that full block, I can verify\n\u003e \u003e the merkle tree myself.\n\u003e \n\u003e Well, it's more efficient to just verify the merkle branch. But yes.\n\nWe're only talking about one verifying one (or minimal numbers of) blocks; \n\"efficient\" isn't really going to matter much in that context. Also, if \nwe're talking about a situation where we don't necessarily trust the remote, \nwe've got to verify the whole block, not just the one transaction we're \ninterested in, since we told the remote which one we were interested in when \nwe requested it.\n\n\u003e \u003e I'm not entirely sure I see how a filter helps. If I've been offline\n\u003e \u003e for ten minutes then I need all the transactions pending in the last\n\u003e \u003e ten minutes. No amount of filtering makes that list any smaller.\n\u003e \n\u003e Why do you need all of them? You just care about the ones sending\n\u003e coins to you, surely?\n\nIs the filter going to be filter-by-address then? I misunderstood in that \ncase, I thought you were talking about filter-by-hash, which obviously tells \nyou nothing about the contents of the transaction.\n\n\u003e \u003e That would be fine. My reason for suggesting using getblocks was that\n\u003e \u003e it didn't introduce a new command.\n\u003e \n\u003e IMHO it's fine to introduce new commands. They'll just be ignored by\n\u003e old clients in any event.\n\nThat's good to know. I'm trying to be circumspect in what my client does; I \nwant to be 100% compatible, which means if I need a new feature, it's got to \nbe in the official client first.\n\nI accept that this is all big talk, and there are plenty of people who start \nnew clients and then give up; which might still happen to me.\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "a4c85fc4eab797cc5b37b7995cf749375b9f4bb6c5e467325a7c535485dd0803e51a70f76893dfbec1a2ec2285679313858b2eb1714bcdb9a6305df1af39ca74"
}