📅 Original date posted:2012-01-02
📝 Original message:It can speed up the initial chain download. A newly created wallet will
have only new key-pairs, hence no incoming transactions (unless we have a
key collision, which is unlikely). So there is no need for a bootstrapping
node to download the chain with transactions. The chain itself can be
verified without the transactions. Later full blocks would be required to
detect usable inputs for future outgoing transactions. As long as you
verify the very last blocks in the chain you can be sure that all
preceeding blocks were also valid.
HTH,
Chris
On Mon, Jan 2, 2012 at 6:04 AM, Elden Tyrell <tyrell.elden at gmail.com> wrote:
> Satoshi's paper mentions that storage requirements for the blockchain
> can be reduced by deleting transactions whose outputs have been spent.
>
> If I understand correctly, this technique can only be used for reducing
> *storage* requirements, not *bandwidth* needed for the initial chain
> download by a high-security client that doesn't trust any of its peers
> -- right?
>
> The rule is "trust the longest valid chain of blocks". Part of a block
> being "valid" is that each transaction's inputs are unspent and their
> sum exceeds the transaction's outputs unless it is a coinbase. This
> cannot be verified for "stubbed out" transactions -- they have outputs
> but no inputs, and aren't coinbases. So a paranoid client booting up
> for the first time needs to be given an un-stubbed chain, right?
>
> Of course, if a client decided to accept a stubbed blocks only when the
> sum of the difficulties in the blocks after it exceeds some number N,
> then attacking it could be made very expensive by picking a large
> enough N.
>
> Please let me know if I have misunderstood something.
>
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120102/d90a3da4/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 02:54:23
in reply to nevent1q…8c8q
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 02:54:23Event JSON
{
"id": "d98f9bf8382b15222b326e40d0aa4a9998bb7ecd25912f9988013ae7af666190",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686106463,
"kind": 1,
"tags": [
[
"e",
"67d9df9b422f0a3c9a61b90726cf3ac3535a5c46f83503e498da2c23e50d0b04",
"",
"root"
],
[
"e",
"cb2f78541a432d912d67c5e079911e8347d80cbdaffb7e2c29ce01a57cb09db8",
"",
"reply"
],
[
"p",
"cb909578c1c5b5fa9fb52a030ac64f353e2d2e7a9376a66f1e78998016d23500"
]
],
"content": "📅 Original date posted:2012-01-02\n📝 Original message:It can speed up the initial chain download. A newly created wallet will\nhave only new key-pairs, hence no incoming transactions (unless we have a\nkey collision, which is unlikely). So there is no need for a bootstrapping\nnode to download the chain with transactions. The chain itself can be\nverified without the transactions. Later full blocks would be required to\ndetect usable inputs for future outgoing transactions. As long as you\nverify the very last blocks in the chain you can be sure that all\npreceeding blocks were also valid.\n\nHTH,\nChris\n\nOn Mon, Jan 2, 2012 at 6:04 AM, Elden Tyrell \u003ctyrell.elden at gmail.com\u003e wrote:\n\n\u003e Satoshi's paper mentions that storage requirements for the blockchain\n\u003e can be reduced by deleting transactions whose outputs have been spent.\n\u003e\n\u003e If I understand correctly, this technique can only be used for reducing\n\u003e *storage* requirements, not *bandwidth* needed for the initial chain\n\u003e download by a high-security client that doesn't trust any of its peers\n\u003e -- right?\n\u003e\n\u003e The rule is \"trust the longest valid chain of blocks\". Part of a block\n\u003e being \"valid\" is that each transaction's inputs are unspent and their\n\u003e sum exceeds the transaction's outputs unless it is a coinbase. This\n\u003e cannot be verified for \"stubbed out\" transactions -- they have outputs\n\u003e but no inputs, and aren't coinbases. So a paranoid client booting up\n\u003e for the first time needs to be given an un-stubbed chain, right?\n\u003e\n\u003e Of course, if a client decided to accept a stubbed blocks only when the\n\u003e sum of the difficulties in the blocks after it exceeds some number N,\n\u003e then attacking it could be made very expensive by picking a large\n\u003e enough N.\n\u003e\n\u003e Please let me know if I have misunderstood something.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex\n\u003e infrastructure or vast IT resources to deliver seamless, secure access to\n\u003e virtual desktops. With this all-in-one solution, easily deploy virtual\n\u003e desktops for less than the cost of PCs and save 60% on VDI infrastructure\n\u003e costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120102/d90a3da4/attachment.html\u003e",
"sig": "9e4ba6cbd4e5d0f04402a596b16da1d54d34c7ec56afa799167cfe19dd8806514f7903dc451608a0649505445a2c34268f820da74f1ce54ba588566a52ea9953"
}