diff options
| author | Kulpreet Singh <zapfmann@gmail.com> | 2019-04-04 12:27:02 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-04-04 10:27:18 +0000 |
| commit | 40533f7b3ff4b70b5b194512157ea78e75b1f3dd (patch) | |
| tree | e359c79f5bcc4a6fd3b27513682f1e993da9b4b7 | |
| parent | aa9148cd0ef11802e4dafc68279a0678e5a3e01b (diff) | |
| download | pi-bitcoindev-40533f7b3ff4b70b5b194512157ea78e75b1f3dd.tar.gz pi-bitcoindev-40533f7b3ff4b70b5b194512157ea78e75b1f3dd.zip | |
Re: [bitcoin-dev] assumeutxo and UTXO snapshots
| -rw-r--r-- | 89/138429416e26dacb184ff20df93216446620c5 | 579 |
1 files changed, 579 insertions, 0 deletions
diff --git a/89/138429416e26dacb184ff20df93216446620c5 b/89/138429416e26dacb184ff20df93216446620c5 new file mode 100644 index 000000000..f43155d60 --- /dev/null +++ b/89/138429416e26dacb184ff20df93216446620c5 @@ -0,0 +1,579 @@ +Return-Path: <zapfmann@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 455D01AF3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Apr 2019 10:27:18 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com + [209.85.208.195]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 392A47A6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Apr 2019 10:27:16 +0000 (UTC) +Received: by mail-lj1-f195.google.com with SMTP id j89so1618760ljb.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 04 Apr 2019 03:27:16 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :content-transfer-encoding; + bh=feIRQ8QUsfj/Etck71WKKX8kGXeALIdrT+b3O3KA2zU=; + b=kYvK9m4kHtefRL1f3Abf8n1JjHny3pJ8cniwqAUdw7wFHzHWydTJSVwo+O7F0rsYTx + z5VhgQcP1BIwK1NS98gBIwVT22SqI5B/E6Ean1p9647RsCmgIIrE54rAWV/0LMeb8ZPi + IQdboFU5Ux1pqxbEwQ/Dsrl9ui6dhiwp11Zt17+afwxznkqcCM8yLBnHjMOp1F2ns4aX + cNMhi7+D2gXcICdOrZrjP/LL3V2YBLtbAil1wL1UBNTMrj4BQhpr2kPjbMcYYM26Aoz/ + hM9YpPQz817RrpqIfltslL005i70fqlIo1xpKGjtvyJ3o00TA57Q9C4XvsNZP0JhieYa + aiMA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:content-transfer-encoding; + bh=feIRQ8QUsfj/Etck71WKKX8kGXeALIdrT+b3O3KA2zU=; + b=s7nkFSXZq1l+3zoiTwrBXmZlGU4FjNy39GWbH9CgPa6GOrA4v6vg2za6Sc4NySLb1P + XODZfnZ0bNmccacIFmKLHiajNwSsOL9muAgonatrFDWPkU/PX6fgZc9PJZcq6PFA/9jP + h8qL/72m55nFozrwRA+/qDfSbbpTfOaqmKTDcZqPS/TqwOVUcZF0KKYSClv96XdLNn8K + aTgGuy1uxgmb6By9XDyvM5Egklj2gmlbR9Lg9Qn6NBDGii6rwTAZ5H/7rb4v/fNkfe2/ + lnMx5OfrhE+FKtEyvGGSkOeT/M/H5dMDqG47EPkAsHFMSumj/KMDosudE92jJVbERh4x + X8Yw== +X-Gm-Message-State: APjAAAUa9aVFZ1r8kqths2I+FKXQdHTprT6c3CqmZIGhqYmUo4FPs1RJ + JUrsl6Pt10DrpHMv4bZW6EtbsXHxY3mJbq90CIY= +X-Google-Smtp-Source: APXvYqySj/q0u8sOko6pbKHdC4iSXdgRfQ+BfIh5SkO2FWh9mxmKRff+7Ck0MSWMOeTCJ8BpzH8zdHhYmTyhqpL90Lg= +X-Received: by 2002:a2e:9655:: with SMTP id z21mr2922989ljh.60.1554373634290; + Thu, 04 Apr 2019 03:27:14 -0700 (PDT) +MIME-Version: 1.0 +References: <mailman.2593.1554248572.29810.bitcoin-dev@lists.linuxfoundation.org> + <CA+1nnrkFWNugSm+o=BrQMLcsO0gNDDCcKRJfDi=5osMZV7o7CA@mail.gmail.com> +In-Reply-To: <CA+1nnrkFWNugSm+o=BrQMLcsO0gNDDCcKRJfDi=5osMZV7o7CA@mail.gmail.com> +From: Kulpreet Singh <zapfmann@gmail.com> +Date: Thu, 4 Apr 2019 12:27:02 +0200 +Message-ID: <CAN8S4uZz_WoAU-TiC4XHq81Vw4-Fzed9xsHzFdLO5m+AHX5JFA@mail.gmail.com> +To: Nicolas Dorier <nicolas.dorier@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Thu, 04 Apr 2019 14:02:45 +0000 +Subject: Re: [bitcoin-dev] assumeutxo and UTXO snapshots +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 04 Apr 2019 10:27:18 -0000 + +Hi Nicolas, + +I have a small question about FastSync. + +Would it make sense to validate all blocks once FastSync is complete +and BTCPayServer has started accepting payments? + +I am aware this will require changes to bitcoind. So this is just an +academic question to figure if there are problems with such an +approach, especially for merchants accepting payments who want to get +started immediately and still want to stay on a Raspberry PI. + +Phase 1: FastSync from trusted UTXO set and start accepting payments. +Phase 2: Validate the entire blockchain - this will take X days on +Raspberry PI - but at least in in the end you can fully trust your own +node. In this phase, you'd do IBD, but instead of writing to db, just +verify that the validated block matches the on the the db and move on. + +It is a pity leveldb doesn't allow multiple processes to open the db. +If so, phase 2 could have been a different process altogether as well. + +Regards +Kulpreet + + + +On Wed, 3 Apr 2019 at 21:23, Nicolas Dorier via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> James, +> +> You might be interested by my work which is currently used in production,= + without any change to bitcoin core. +> +> I properly explain how to verify the utxoset independently. +> +> https://github.com/btcpayserver/btcpayserver-docker/blob/master/contrib/F= +astSync/README.md +> +> People are using it, since I get around 10 download a day. +> What can be done to help at Bitcoin Core level is actually very minimal. +> +> First, instead of asking signers of by UTXOSet to sign the utxoset hash f= +rom gettxoutsetinfo, I ask them to sign the hash of the tarball of my UTXO = +Set. +> +> The reason is that it is currently impossible to stop BitcoinD on a speci= +fic block then asking the serialized hash of the UTXO Set. +> +> So instead, a verifier download the tarball (300 blocks + utxoset at spec= +ific height), sync to the latest block, then compare the gettxoutsetinfo of= + the newly synched node with another trusted node. If it match, the verifie= +r sign the tarball. +> +> I create a new utxoset snapshot every 6 months, so people have time to ve= +rify it and add their signatures. (Approximately once every bitcoin core re= +lease) +> +> The easiest thing that could be done at Bitcoin Core level does not requi= +re any code change, but a change in the release process. +> +> The new process would be to ask to the gitian signers to not only build t= +he source themselves, but also verify a tarball following the procedure I e= +xplain in the link above. +> +> More complicated solution like signing the serialized utxoset itself, whi= +le possible, would require bothersome code changes. +> +> Nicolas, +> +> On Wed, Apr 3, 2019 at 9:25 AM <bitcoin-dev-request@lists.linuxfoundation= +.org> wrote: +>> +>> Send bitcoin-dev mailing list submissions to +>> bitcoin-dev@lists.linuxfoundation.org +>> +>> To subscribe or unsubscribe via the World Wide Web, visit +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> or, via email, send a message with subject or body 'help' to +>> bitcoin-dev-request@lists.linuxfoundation.org +>> +>> You can reach the person managing the list at +>> bitcoin-dev-owner@lists.linuxfoundation.org +>> +>> When replying, please edit your Subject line so it is more specific +>> than "Re: Contents of bitcoin-dev digest..." +>> +>> +>> Today's Topics: +>> +>> 1. BIP: Bitcoin Integrated Address Feature? (nathanw@tutanota.com) +>> 2. Re: BIP: Bitcoin Integrated Address Feature? (htimSxelA) +>> 3. assumeutxo and UTXO snapshots (James O'Beirne) +>> +>> +>> ---------------------------------------------------------------------- +>> +>> Message: 1 +>> Date: Tue, 2 Apr 2019 18:53:11 +0200 (CEST) +>> From: <nathanw@tutanota.com> +>> To: <bitcoin-dev@lists.linuxfoundation.org> +>> Subject: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature? +>> Message-ID: <LbTxyE4--3-1@tutanota.com> +>> Content-Type: text/plain; charset=3D"utf-8" +>> +>> To whom it may concern, +>> +>> I believe a missing feature in Bitcoin is the ability to have an "integr= +ated address", where the address resolves into a Bitcoin address, and also = +a transaction message or some other kind of identifier. +>> +>> By having this feature we could enhance the security of exchange cold-wa= +llet systems, by allowing them to easily receive all payments to a single a= +ddress from an infinite number of customers. We would also greatly simplify= + the process of setting up and managing exchange cold-wallet systems, becau= +se we would eliminate the "sweeping" step required to move multiple custome= +r deposits from a hot address into a single cold address. +>> +>> Although it would be nice to have all customers deposit directly into co= +ld addresses, this quickly becomes impractical when large amounts of custom= +ers begin to use exchange wallets as their personal web-wallet, frequently = +depositing and withdrawing without trading action. You end up needing to ha= +ve a staff member moving funds away from cold deposit addresses as a full t= +ime job - if you wish to handle customer funds in a completely secure manne= +r. +>> +>> Thus we see that most exchanges now use the hot-deposit system, where cu= +stomers deposit into a hot address that is then automatically swept into a = +singular cold address, by a service which holds customers private keys onli= +ne. You can observe this service at work simply by making a deposit to most= + major exchanges (including the largest exchange Binance), as you will see = +the funds quickly being "swept" to their cold wallet address in a manner wh= +ich heavily suggests automation by a program which possesses private keys t= +o the address you are sending funds to. This means there is always the dang= +er of a sophisticated hacker being able to capture private keys to customer= + deposit addresses (as they are clearly being held online). An integrated a= +ddress would allow all exchanges using this automated hot-deposit service t= +o easily switch to a far more secure alternative of having all customers de= +positing directly into their singular cold wallet address. +>> +>> There are several other more minor advantages such a feature would have,= + including: +>> - Lower fees for exchanges (which could be passed onto customers), by re= +ducing a transaction step out of the deposit-to-withdrawal flow. +>> - Less need for large rescans after loading huge amounts of customer add= +resses into client software. +>> - Exchanges can more easily provision deposit addresses to new customers= + in a secure manner, by simply generating a hex or other value, creating an= + integrated address from the cold wallet address, and then providing this t= +o the customer. +>> - By providing a singular cold address for exchanges publicly, customers= + can more easily verify that no man-in-the-middle has given them an incorre= +ct address to deposit to. +>> The integrated address could work by combining the Bitcoin address toget= +her with some kind of hex or other value, allowing users to choose the amou= +nt they wish to deposit themselves, but ensuring their deposits are uniquel= +y trackable. +>> +>> I'm not sure if some kind of functionality already exists in BTC, as I h= +aven't been able to find it. If not, can I submit a proposal to implement t= +his? This feature would be a godsend to all exchange developers if it was w= +idely accepted. +>> +>> Thanks for your time. +>> Regards, +>> +>> Nathan Worsley +>> CTO - LocalCoinSwap.Com +>> -------------- next part -------------- +>> An HTML attachment was scrubbed... +>> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments= +/20190402/400c1e1b/attachment-0001.html> +>> +>> ------------------------------ +>> +>> Message: 2 +>> Date: Tue, 02 Apr 2019 20:01:34 +0000 +>> From: htimSxelA <htimsxela@protonmail.com> +>> To: "nathanw@tutanota.com" <nathanw@tutanota.com>, Bitcoin Protocol +>> Discussion <bitcoin-dev@lists.linuxfoundation.org> +>> Subject: Re: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature? +>> Message-ID: +>> <wtbAF1FAGePDAkY3xkqANuFJtAhEXvz0JeGWnc_OZcGEyFQb-1B590I3IbwtW2F= +Bivur0yONbSQtxaWqiQTJeoDdadivtbGkWwJnLnnzQQE=3D@protonmail.com> +>> +>> Content-Type: text/plain; charset=3D"utf-8" +>> +>> Hello, +>> +>> I see two immediate issues with this: +>> 1. Increased resource requirements per transaction +>> 2. Embedding identifying information into the blockchain is generally ba= +d for privacy +>> +>> It may help your case to provide some technical details of how you'd lik= +e to see this implemented, but without overcoming the issues mentioned abov= +e I think this proposal will be a very tough sell. +>> +>> > ...this quickly becomes impractical when large amounts of customers be= +gin to use exchange wallets as their personal web-wallet, frequently deposi= +ting and withdrawing without trading action. You end up needing to have a s= +taff member moving funds away from cold deposit addresses as a full time jo= +b - if you wish to handle customer funds in a completely secure manner. +>> +>> I am not sure if I see how this issue is solved by your proposal. Assume= +dly, a human will still need to manually approve cold-wallet withdrawals in= + order to maintain security. So it seems to me that removing the 'hot-walle= +t' component of the backend would only amplify the need for human interacti= +on. +>> +>> I assume you are familiar with hierarchical deterministic wallets? They = +can allow an exchange to assign/identify user deposits based on address der= +ivation path. Keys for deposit addresses can be kept offline if wanted, and= + a proper implementation of an HD wallet system should also remove the need= + for rescans of user deposit addresses. +>> +>> There is also a functionality built into Bitcoin that allows a user to p= +rove that they own the private keys to some address: signing an agreed upon= + message using the private key that controls that address. Unfortunately I = +don't think this is a workable solution for you, since the majority of mode= +rn wallet software does not include this feature-- but perhaps worth mentio= +ning nonetheless. +>> +>> Best, +>> Alex +>> +>> ??????? Original Message ??????? +>> On Tuesday, April 2, 2019 9:53 AM, Nathan Worsley via bitcoin-dev <bitco= +in-dev@lists.linuxfoundation.org> wrote: +>> +>> > To whom it may concern, +>> > +>> > I believe a missing feature in Bitcoin is the ability to have an "inte= +grated address", where the address resolves into a Bitcoin address, and als= +o a transaction message or some other kind of identifier. +>> > +>> > By having this feature we could enhance the security of exchange cold-= +wallet systems, by allowing them to easily receive all payments to a single= + address from an infinite number of customers. We would also greatly simpli= +fy the process of setting up and managing exchange cold-wallet systems, bec= +ause we would eliminate the "sweeping" step required to move multiple custo= +mer deposits from a hot address into a single cold address. +>> > +>> > Although it would be nice to have all customers deposit directly into = +cold addresses, this quickly becomes impractical when large amounts of cust= +omers begin to use exchange wallets as their personal web-wallet, frequentl= +y depositing and withdrawing without trading action. You end up needing to = +have a staff member moving funds away from cold deposit addresses as a full= + time job - if you wish to handle customer funds in a completely secure man= +ner. +>> > +>> > Thus we see that most exchanges now use the hot-deposit system, where = +customers deposit into a hot address that is then automatically swept into = +a singular cold address, by a service which holds customers private keys on= +line. You can observe this service at work simply by making a deposit to mo= +st major exchanges (including the largest exchange Binance), as you will se= +e the funds quickly being "swept" to their cold wallet address in a manner = +which heavily suggests automation by a program which possesses private keys= + to the address you are sending funds to. This means there is always the da= +nger of a sophisticated hacker being able to capture private keys to custom= +er deposit addresses (as they are clearly being held online). An integrated= + address would allow all exchanges using this automated hot-deposit service= + to easily switch to a far more secure alternative of having all customers = +depositing directly into their singular cold wallet address. +>> > +>> > There are several other more minor advantages such a feature would hav= +e, including: +>> > - Lower fees for exchanges (which could be passed onto customers), by = +reducing a transaction step out of the deposit-to-withdrawal flow. +>> > - Less need for large rescans after loading huge amounts of customer a= +ddresses into client software. +>> > - Exchanges can more easily provision deposit addresses to new custome= +rs in a secure manner, by simply generating a hex or other value, creating = +an integrated address from the cold wallet address, and then providing this= + to the customer. +>> > - By providing a singular cold address for exchanges publicly, custome= +rs can more easily verify that no man-in-the-middle has given them an incor= +rect address to deposit to. +>> > +>> > The integrated address could work by combining the Bitcoin address tog= +ether with some kind of hex or other value, allowing users to choose the am= +ount they wish to deposit themselves, but ensuring their deposits are uniqu= +ely trackable. +>> > +>> > I'm not sure if some kind of functionality already exists in BTC, as I= + haven't been able to find it. If not, can I submit a proposal to implement= + this? This feature would be a godsend to all exchange developers if it was= + widely accepted. +>> > +>> > Thanks for your time. +>> > +>> > Regards, +>> > +>> > Nathan Worsley +>> > CTO - LocalCoinSwap.Com +>> -------------- next part -------------- +>> An HTML attachment was scrubbed... +>> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments= +/20190402/ade34235/attachment-0001.html> +>> +>> ------------------------------ +>> +>> Message: 3 +>> Date: Tue, 2 Apr 2019 16:43:11 -0400 +>> From: "James O'Beirne" <james.obeirne@gmail.com> +>> To: bitcoin-dev@lists.linuxfoundation.org +>> Subject: [bitcoin-dev] assumeutxo and UTXO snapshots +>> Message-ID: +>> <CAPfvXf+JS6ZhXUieWVxiaNa4uhhWwafCk3odMKy5F_yi=3DXwngA@mail.gmai= +l.com> +>> Content-Type: text/plain; charset=3D"utf-8" +>> +>> Hi, +>> +>> I'd like to discuss assumeutxo, which is an appealing and simple +>> optimization in the spirit of assumevalid[0]. +>> +>> # Motivation +>> +>> To start a fully validating bitcoin client from scratch, that client +>> currently +>> needs to perform an initial block download. To the surprise of no one, I= +BD +>> takes a linear amount time based on the length of the chain's history. F= +or +>> clients running on modest hardware under limited bandwidth constraints, +>> say a mobile device, completing IBD takes a considerable amount of time +>> and thus poses serious usability challenges. +>> +>> As a result, having fully validating clients run on such hardware is rar= +e +>> and +>> basically unrealistic. Clients with even moderate resource constraints +>> are encouraged to rely on the SPV trust model. Though we have promising +>> improvements to existing SPV modes pending deployment[1], it's worth +>> thinking about a mechanism that would allow such clients to use trust +>> models closer to full validation. +>> +>> The subject of this mail is a proposal for a complementary alternative t= +o +>> SPV +>> modes, and which is in the spirit of an existing default, `assumevalid`.= + It +>> may +>> help modest clients transact under a security model that closely resembl= +es +>> full validation within minutes instead of hours or days. +>> +>> # assumeutxo +>> +>> The basic idea is to allow nodes to initialize using a serialized versio= +n +>> of the +>> UTXO set rendered by another node at some predetermined height. The +>> initializing node syncs the headers chain from the network, then obtains= + and +>> loads one of these UTXO snapshots (i.e. a serialized version of the UTXO= + set +>> bundled with the block header indicating its "base" and some other +>> metadata). +>> +>> Based upon the snapshot, the node is able to quickly reconstruct its +>> chainstate, +>> and compares a hash of the resulting UTXO set to a preordained hash +>> hard-coded +>> in the software a la assumevalid. This all takes ~23 minutes, not +>> accounting for +>> download of the 3.2GB snapshot[2]. +>> +>> The node then syncs to the network tip and afterwards begins a simultane= +ous +>> background validation (i.e., a conventional IBD) up to the base height o= +f +>> the +>> snapshot in order to achieve full validation. Crucially, even while the +>> background validation is happening the node can validate incoming blocks= + and +>> transact with the benefit of the full (assumed-valid) UTXO set. +>> +>> Snapshots could be obtained from multiple separate peers in the same man= +ner +>> as +>> block download, but I haven't put much thought into this. In concept it +>> doesn't +>> matter too much where the snapshots come from since their validity is +>> determined via content hash. +>> +>> # Security +>> +>> Obviously there are some security implications due consideration. While = +this +>> proposal is in the spirit of assumevalid, practical attacks may become +>> easier. +>> Under assumevalid, a user can be tricked into transacting under a false +>> history +>> if an attacker convinces them to start bitcoind with a malicious +>> `-assumevalid` +>> parameter, sybils their node, and then feeds them a bogus chain encompas= +sing +>> all of the hard-coded checkpoints[3]. +>> +>> The same attack is made easier in assumeutxo because, unlike in assumeva= +lid, +>> the attacker need not construct a valid PoW chain to get the victim's no= +de +>> into +>> a false state; they simply need to get the user to accept a bad +>> `-assumeutxo` +>> parameter and then supply them an easily made UTXO snapshot containing, +>> say, a +>> false coin assignment. +>> +>> For this reason, I recommend that if we were to implement assumeutxo, we= + not +>> allow its specification via commandline argument[4]. +>> +>> Beyond this risk, I can't think of material differences in security +>> relative to +>> assumevalid, though I appeal to the list for help with this. +>> +>> # More fully validating clients +>> +>> A particularly exciting use-case for assumeutxo is the possibility of mo= +bile +>> devices functioning as fully validating nodes with access to the complet= +e +>> UTXO +>> set (as an alternative to SPV models). The total resource burden needed = +to +>> start a node +>> from scratch based on a snapshot is, at time of writing, a ~(3.2GB +>> + blocks_to_tip * 4MB) download and a few minutes of processing time, wh= +ich +>> sounds +>> manageable for many mobile devices currently in use. +>> +>> A mobile user could initialize an assumed-valid bitcoin node within an h= +our, +>> transact immediately, and complete a pruned full validation of their +>> assumed-valid chain over the next few days, perhaps only doing the +>> background +>> IBD when their device has access to suitable high-bandwidth connections. +>> +>> If we end up implementing an accumulator-based UTXO scaling design[5][6] +>> down +>> the road, it's easy to imagine an analogous process that would allow ver= +y +>> fast +>> startup using an accumulator of a few kilobytes in lieu of a multi-GB +>> snapshot. +>> +>> --- +>> +>> I've created a related issue at our Github repository here: +>> https://github.com/bitcoin/bitcoin/issues/15605 +>> +>> and have submitted a draft implementation of snapshot usage via RPC here= +: +>> https://github.com/bitcoin/bitcoin/pull/15606 +>> +>> I'd like to discuss here whether this is a good fit for Bitcoin +>> conceptually. Concrete +>> plans for deployment steps should be discussed in the Github issue, and +>> after all +>> that my implementation may be reviewed as a sketch of the specific softw= +are +>> changes necessary. +>> +>> Regards, +>> James +>> +>> +>> [0]: +>> https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-bloc= +ks +>> [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki +>> [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU= + @ +>> 2.10GHz +>> [3]: +>> https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145= +-L161 +>> [4]: Marco Falke is due credit for this point +>> [5]: utreexo: https://www.youtube.com/watch?v=3DedRun-6ubCc +>> [6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/11= +88 +>> -------------- next part -------------- +>> An HTML attachment was scrubbed... +>> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments= +/20190402/46b25dd8/attachment.html> +>> +>> ------------------------------ +>> +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +>> +>> End of bitcoin-dev Digest, Vol 47, Issue 6 +>> ****************************************** +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + |