path: root/89/138429416e26dacb184ff20df93216446620c5

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