📅 Original date posted:2011-07-07
🗒️ Summary of this message: A proposal for two changes to the Bitcoin protocol, including the ability for lightweight clients to request transactions and a virtual block for pending transactions.
📝 Original message:Hello,
This is a suggestion with a mind to the future. In particular, I'm slowly
working on an alternative client and library (I know, everyone says that).
I've got a feature that I'd like to have that would need a change in the
protocol. It's a change that I think would improve the official client as
well, so I'm bringing it up here.
It's actually two changes; and both could be acheived by adding new commands
to the protocol. I think that would be overkill though; as they fit quite
nicely into an extended getblocks command.
(1) The getblocks message is a list of inventory items (type MSG_BLOCK) being
requested.
Imagine this situation though. I am a light weight client. I store the block
headers only. I am only interested in the history of my own wallet addresses.
I receive a block broadcast with a transaction that sends coins to one of my
addresses. That transaction references other transactions (of course), but I
haven't stored any transactions. So; I want to request those transactions and
ensure they are all valid and in blocks. I can't.
I can request the transactions themselves; but I have no way of finding out
what block they were in without downloading the entire full block chain
myself. The thing is, a peer with the full block chain is able to do this
instantly.
Here then is my suggestion: getblocks should accept inventory items of type
MSG_TX as well as MSG_BLOCK. When it finds a MSG_TX request, it shouldn't
send the transaction (after all that is what the getdata message is for);
instead it should return the block that contains that transaction. It's an
alternative way of requesting a block -- by transaction in that block.
It should be obvious then that it would be easy for a lightweight client to
request the transaction chain transactions its interested in to create a list
of relevant hashes for the history it's after; and then put those hashes in a
getblocks request and have to look only at a few full blocks instead of the
full block chain.
(2) If you are offline when new transactions are broadcast, there is no way to
know they are pending.
Transactions that have been broadcast but not yet accepted into a block are
never resent (nor should they be). But if I am on a mobile client say, or a
light-weight, intermittently used client; I have no way of checking if a
transaction sending coins to one of my addresses is pending.
It should be possible to request the current pending transaction list.
My sugestion then is that a special virtual block request be possible. The
all zero block hash can never exist (it's used as the parent for the genesis
block, so it had better not). If I send a getblocks that contains an all-zero
hash, then the virtual block should be returned in a block message. That
virtual block will list all the current pending transactions. Obviously there
would be a problem that it's actual hash would not be zero; so it would have
to be marked as the virtual block in some other way (perhaps a zero timestamp
plus a zero parent hash, or similar).
The combination of the above two protocol changes makes it possible for any
client to have a large chunk of the facilities available in blockexplorer.com
and the very useful http://bitcoincharts.com/bitcoin/ information.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nx…7wjrv
2023-06-07 02:03:15
in reply to nevent1q…nsuc
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 02:03:15Event JSON
{
"id": "f524b25c4c2c39c450c4b4fc4654c5c77914f6a0ed96852fac1cbc85164bed2b",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686103395,
"kind": 1,
"tags": [
[
"e",
"9937cd991e90b8eac747cbbc95f665ee02332070c215333b4ec526b53cec3cee",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2011-07-07\n🗒️ Summary of this message: A proposal for two changes to the Bitcoin protocol, including the ability for lightweight clients to request transactions and a virtual block for pending transactions.\n📝 Original message:Hello,\n\nThis is a suggestion with a mind to the future. In particular, I'm slowly \nworking on an alternative client and library (I know, everyone says that). \nI've got a feature that I'd like to have that would need a change in the \nprotocol. It's a change that I think would improve the official client as \nwell, so I'm bringing it up here.\n\nIt's actually two changes; and both could be acheived by adding new commands \nto the protocol. I think that would be overkill though; as they fit quite \nnicely into an extended getblocks command.\n\n(1) The getblocks message is a list of inventory items (type MSG_BLOCK) being \nrequested.\n\nImagine this situation though. I am a light weight client. I store the block \nheaders only. I am only interested in the history of my own wallet addresses. \nI receive a block broadcast with a transaction that sends coins to one of my \naddresses. That transaction references other transactions (of course), but I \nhaven't stored any transactions. So; I want to request those transactions and \nensure they are all valid and in blocks. I can't.\n\nI can request the transactions themselves; but I have no way of finding out \nwhat block they were in without downloading the entire full block chain \nmyself. The thing is, a peer with the full block chain is able to do this \ninstantly.\n\nHere then is my suggestion: getblocks should accept inventory items of type \nMSG_TX as well as MSG_BLOCK. When it finds a MSG_TX request, it shouldn't \nsend the transaction (after all that is what the getdata message is for); \ninstead it should return the block that contains that transaction. It's an \nalternative way of requesting a block -- by transaction in that block.\n\nIt should be obvious then that it would be easy for a lightweight client to \nrequest the transaction chain transactions its interested in to create a list \nof relevant hashes for the history it's after; and then put those hashes in a \ngetblocks request and have to look only at a few full blocks instead of the \nfull block chain.\n\n\n(2) If you are offline when new transactions are broadcast, there is no way to \nknow they are pending.\n\nTransactions that have been broadcast but not yet accepted into a block are \nnever resent (nor should they be). But if I am on a mobile client say, or a \nlight-weight, intermittently used client; I have no way of checking if a \ntransaction sending coins to one of my addresses is pending.\n\nIt should be possible to request the current pending transaction list.\n\nMy sugestion then is that a special virtual block request be possible. The \nall zero block hash can never exist (it's used as the parent for the genesis \nblock, so it had better not). If I send a getblocks that contains an all-zero \nhash, then the virtual block should be returned in a block message. That \nvirtual block will list all the current pending transactions. Obviously there \nwould be a problem that it's actual hash would not be zero; so it would have \nto be marked as the virtual block in some other way (perhaps a zero timestamp \nplus a zero parent hash, or similar).\n\n\n\nThe combination of the above two protocol changes makes it possible for any \nclient to have a large chunk of the facilities available in blockexplorer.com \nand the very useful http://bitcoincharts.com/bitcoin/ information.\n\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "4dcd499560009335720243d9324aaa756d15f6b1ae34afd18f5f6425402a3f5f7b4dc455615671b16d6097180048b299032f942b45ada754fb1ed1fc3a7b0cf2"
}