From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EF6DFBA3 for ; Wed, 29 Mar 2017 20:28:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96A92FF for ; Wed, 29 Mar 2017 20:28:35 +0000 (UTC) Received: from [192.168.50.29] ([24.86.172.170]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MaIsi-1cZaOV3kAy-00Jw2e; Wed, 29 Mar 2017 22:28:32 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Peter R In-Reply-To: Date: Wed, 29 Mar 2017 13:28:29 -0700 Message-Id: References: To: Daniele Pinna , Bitcoin Protocol Discussion X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:OiyGvustTO7ixBAyuabNyLmiAkEFTo8Ug5twNjSzTniKewv0o9p zr10gpyLd1g3GosHxhsjfHhLUsfVleUQBJxE20US2gc+rqLjpH7ocmX542OL4RLYPEE/mL4 k1rAtraIQr1GCDbywz9+d42szKcTXIzypdCqEtNzPLTvZkbton15tYEuTQVLPn6U5RE3zk5 9WrMJLQGcuN9ke5e1jA/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:OaRDYIeyilU=:1Qau8Bow8kihIJjetOIUlB oxfqFN1w7AspZE2aSUGG/gB0sQMgLk/+UgKSKHGZo2RsW+PX02OAAwT1ZcCKi4QVpWmSqwsmp 9aeFJk1J3BDR7b13tchnx9DMhUpla4EKkf7texg/elQbn8o09W0WkzIpJIKf1mfvjviGheueA 7JN0hEaBgyTcM6z9Nf5VrJKBBYI0XiEiUULxJ5u5oqeEz3djlHNByd0npuZrh9nHRVUQEL1HP L2AaYHJiTaJ6NlY9bE32NK7LCubvL3SDqYjeuHstqWB+sV7J5AAXMUbfIbP/CDrYnV0+7LLZr 8Pv54ksy16JPBDkICZi2Lcc6YDVqFFibM7TyEbym/8Z796KL2+XR1z0PwhdSVcl4cgwDvOf94 z0l+5X7zXd3zaEOpAMU8Ms3sQfK/mssWQwDFgnrak023XsnJa74CSbModXRxoU9F/a8Y+JUBN Mq6x5iPnK3GOvVS8STMlmIC5LVLO3MurapB8n/efXXPJEo8SlupvGtt+pQID4hFuc3Sifjdqx nn3dfDLv2EeKG3CwallRcqmAWTW2fmLYgm5uABNz21OZFpBNfiK84yGRDxVRx9QV2KE9uR8M7 rMc8IFMIyN7kY843UB5am/gHvs3IVvMYP3ceR60Q+o2vQbBZBJ7+e+AxWJPfa2nRPd1PkLdHJ ZR28gtXeZEowRaHFMkwSMWAcWuD9GvOOzNGUqSN0eC/+/7WybjL8r2K3sSAIkNhiimqx7Se3a Vj/owkRZslxElC37ma0ow9W5sypUzozHjv15UzAEeud+nBv+t8qB88Jevu4+AvAeL23Ojk1PJ TdVb0Y1 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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: Wed, 29 Mar 2017 20:30:24 +0000 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:28:37 -0000 --Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I believe nearly everyone at Bitcoin Unlimited would be supportive of a = UTXO check-pointing scheme. I=E2=80=99d love to see this happen, as it = would greatly reduce the time needed to get a new node up-and-running, = for node operators who are comfortable trusting these commitments. =20 I=E2=80=99m confident that we could work with the miners who we have = good relationships with to start including the root hash of the = (lagging) UTXO set in their coinbase transactions, in order to begin = transforming this idea into reality. We could also issue regular = transactions from =E2=80=9Csemi-trusted=E2=80=9D addresses controlled by = known people that include the same root hash in an OP_RETURN output, = which would allow cross-checking against the miners=E2=80=99 UTXO = commitments, as part of this initial =E2=80=9Cprototype=E2=80=9D system. This would "get the ball rolling" on UTXO commitments in a = permissionless way (no one can stop us from doing this). If the results = from this prototype commitment scheme were positive, then perhaps there = would be support from the community and miners to enforce a new rule = which requires the (lagging) root hashes be included in new blocks. At = that point, the UTXO commitment scheme is no longer a prototype but a = trusted feature of the Bitcoin network. =20 On that topic, are there any existing proposals detailing a canonical = ordering of the UTXO set and a scheme to calculate the root hash? Best regards, Peter > On Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev = wrote: >=20 > What about periodically committing the entire UTXO set to a special = checkpoint block which becomes the new de facto Genesis block?=20 >=20 > Daniele=20 >=20 > ------------------------------ >=20 > Message: 5 > Date: Wed, 29 Mar 2017 16:41:29 +0000 > From: Andrew Johnson > > To: David Vorick > > Cc: Bitcoin Dev > > Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting > Message-ID: > = > > Content-Type: text/plain; charset=3D"utf-8" >=20 > I believe that as we continue to add users to the system by scaling > capacity that we will see more new nodes appear, but I'm at a bit of a = loss > as to how to empirically prove it. >=20 > I do see your point on increasing load on archival nodes, but the = majority > of that load is going to come from new nodes coming online, they're = the > only ones going after very old blocks. I could see that as a = potential > attack vector, overwhelm the archival nodes by spinning up new nodes > constantly, therefore making it difficult for a "real" new node to get = up > to speed in a reasonable amount of time. >=20 > Perhaps the answer there would be a way to pay an archival node a = small > amount of bitcoin in order to retrieve blocks older than a certain = cutoff? > Include an IP address for the node asking for the data as metadata in = the > transaction... Archival nodes could set and publish their own policy, = let > the market decide what those older blocks are worth. Would also help = to > incentivize running archival node, which we do need. Of course, this = isn't > very user friendly. >=20 > We can take this to bitcoin-discuss, if we're getting too far off = topic. >=20 >=20 > On Wed, Mar 29, 2017 at 11:25 AM David Vorick > > wrote: >=20 > > > > On Mar 29, 2017 12:20 PM, "Andrew Johnson" = > > > wrote: > > > > What's stopping these users from running a pruned node? Not every = node > > needs to store a complete copy of the blockchain. > > > > > > Pruned nodes are not the default configuration, if it was the = default > > configuration then I think you would see far more users running a = pruned > > node. > > > > But that would also substantially increase the burden on archive = nodes. > > > > > > Further discussion about disk space requirements should be taken to > > another thread. > > > > > > -- > Andrew Johnson > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: = > >=20 > ------------------------------ > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I believe nearly everyone at Bitcoin Unlimited would be = supportive of a UTXO check-pointing scheme.  I=E2=80=99d love to = see this happen, as it would greatly reduce the time needed to get a new = node up-and-running, for node operators who are comfortable trusting = these commitments.  

I=E2=80=99m confident that we could work with the miners who = we have good relationships with to start including the root hash of the = (lagging) UTXO set in their coinbase transactions, in order to begin = transforming this idea into reality.  We could also issue regular = transactions from =E2=80=9Csemi-trusted=E2=80=9D addresses controlled by = known people that include the same root hash in an OP_RETURN output, = which would allow cross-checking against the miners=E2=80=99 UTXO = commitments, as part of this initial =E2=80=9Cprototype=E2=80=9D = system.

This = would "get the ball rolling" on UTXO commitments in a permissionless way = (no one can stop us from doing this). If the results from this prototype = commitment scheme were positive, then perhaps there would be support = from the community and miners to enforce a new rule which requires the = (lagging) root hashes be included in new blocks.  At that point, = the UTXO commitment scheme is no longer a prototype but a trusted = feature of the Bitcoin network.    

On that topic, are there any existing = proposals detailing a canonical ordering of the UTXO set and a scheme to = calculate the root hash?

Best regards,
Peter


On = Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

What about periodically = committing the entire UTXO set to a special checkpoint block which = becomes the new de facto Genesis block? 

Daniele 

------------------------------

Message: = 5
Date: Wed, 29 Mar 2017 16:41:29 +0000
From: = Andrew Johnson <andrew.johnson83@gmail.com>
To: David = Vorick <david.vorick@gmail.com>
Cc: = Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: = Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Message-ID:
  =       <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

I believe = that as we continue to add users to the system by scaling
capacity = that we will see more new nodes appear, but I'm at a bit of a = loss
as to how to empirically prove it.

I do see = your point on increasing load on archival nodes, but the = majority
of that load is going to come from new nodes coming online, = they're the
only ones going after very old blocks.   I could = see that as a potential
attack = vector, overwhelm the archival nodes by spinning up new nodes
constantly,= therefore making it difficult for a "real" new node to get up
to speed = in a reasonable amount of time.

Perhaps = the answer there would be a way to pay an archival node a = small
amount of bitcoin in order to retrieve blocks older than a = certain cutoff?
Include = an IP address for the node asking for the data as metadata in = the
transaction...  Archival nodes could set and publish = their own policy, let
the = market decide what those older blocks are worth.  Would also help = to
incentivize running archival node, which we do need.  Of = course, this isn't
very user = friendly.

We can take this to bitcoin-discuss, if we're getting too far = off topic.


On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick@gmail.com>
wrote:

>
> On = Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83@gmail.com>
> = wrote:
>
> = What's stopping these users from running a pruned node?  Not every = node
> needs to store a complete copy of the = blockchain.
>
>
> = Pruned nodes are not the default configuration, if it was the = default
> configuration then I think you would see far more users = running a pruned
> = node.
>
> But = that would also substantially increase the burden on archive = nodes.
>
>
> = Further discussion about disk space requirements should be taken = to
> another thread.
>
>
> = --
Andrew Johnson
-------------- next part --------------
An HTML = attachment was scrubbed...
URL: = <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment.html>

------------------------------
_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511--