public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jared Lee Richardson <jaredr26@gmail.com>
To: Peter R <peter_r@gmx.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Date: Wed, 29 Mar 2017 15:17:40 -0700	[thread overview]
Message-ID: <CAD1TkXsv3cu4w-vEJ5=jPxFC6EHr0ryGNy5ao3RrDNDCn5xELQ@mail.gmail.com> (raw)
In-Reply-To: <E54123C8-F124-449A-9C65-F40FA6917813@gmx.com>

[-- Attachment #1: Type: text/plain, Size: 6806 bytes --]

> I’m 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.

By itself, this wouldn't work without a way for a new node to differentiate
between a false history and a true one.

>  We could also issue regular transactions from “semi-trusted” addresses
controlled by known people that include the same root hash in an OP_RETURN
output, which would allow cross-checking against the miners’ UTXO
commitments, as part of this initial “prototype”

This might work, but I fail to understand how a new node could verify an
address / transaction without a blockchain to back it.  Even if it could,
it becomes dependent upon those addresses not being compromised, and the
owners of those addresses would become targets for potential government
operations.

Having the software silently attempt to resolve the problem is risky unless
it is foolproof.  Otherwise, users will assume their software is showing
them the correct history/numbers implicitly, and if the change the utxo
attacker made was small, the users might be able to follow the main chain
totally until it was too late and the attacker struck with an address that
otherwise never transacted.  Sudden, bizarre, hard to debug fork and
potentially double spend against people who picked up the fraudulent utxo.

Users already treat wallet software with some level of suspicion, asking if
they can trust x or y or z, or like the portion of the BU community
convinced that core has been compromised by blockstream bigwigs.  Signed
releases could provide the same thing but would encourage both open-source
security checks of the signed utxo's and potentially of users to check
download signatures.

Either approach is better than what we have now though, so I'd support
anything.

On Wed, Mar 29, 2017 at 1:28 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I believe nearly everyone at Bitcoin Unlimited would be supportive of a
> UTXO check-pointing scheme.  I’d 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’m 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
> “semi-trusted” addresses controlled by known people that include the same
> root hash in an OP_RETURN output, which would allow cross-checking against
> the miners’ UTXO commitments, as part of this initial “prototype” 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.gm
> ail.com>
> Content-Type: text/plain; charset="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/atta
> chments/20170329/9b48ebe3/attachment.html>
>
> ------------------------------
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 16781 bytes --]

  reply	other threads:[~2017-03-29 22:17 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 19:33 [bitcoin-dev] Hard fork proposal from last week's meeting Daniele Pinna
2017-03-29 20:28 ` Peter R
2017-03-29 22:17   ` Jared Lee Richardson [this message]
2017-03-29 20:28 ` David Vorick
2017-03-29 22:08   ` Jared Lee Richardson
2017-03-30  7:11     ` Luv Khemani
2017-03-30 17:16       ` Jared Lee Richardson
2017-03-31  4:21         ` Luv Khemani
2017-03-31  5:28           ` Jared Lee Richardson
2017-03-31  8:19             ` Luv Khemani
2017-03-31 15:59               ` Jared Lee Richardson
2017-03-31 16:14                 ` David Vorick
2017-03-31 16:46                   ` Jared Lee Richardson
2017-03-31 18:23                     ` David Vorick
2017-03-31 18:58                       ` Eric Voskuil
2017-04-01  6:15                       ` Jared Lee Richardson
  -- strict thread matches above, loose matches on Subject: below --
2017-03-31 21:23 Rodney Morris
2017-03-31 23:13 ` Eric Voskuil
     [not found]   ` <CABerxhGeofH4iEonjB1xKOkHcEVJrR+D4QhHSw5cWYsjmW4JpQ@mail.gmail.com>
2017-04-01  1:41     ` Rodney Morris
2017-04-01  6:18   ` Jared Lee Richardson
2017-04-01  7:41     ` Eric Voskuil
     [not found]       ` <CAAt2M1_sHsCD_AX-vm-oy-4tY+dKoDAJhfVUc4tnoNBFn-a+Dg@mail.gmail.com>
     [not found]         ` <CAAt2M19Gt8PmcPUGUHKm2kpMskpN4soF6M-Rb46HazKMV2D9mg@mail.gmail.com>
2017-04-01 14:45           ` Natanael
     [not found]       ` <CAD1TkXusCe-O3CGQkXyRw_m3sXS9grGxMqkMk8dOvFNXeV5zGQ@mail.gmail.com>
2017-04-01 18:42         ` Jared Lee Richardson
     [not found]   ` <CAAt2M1_kuCBQWd9dis5UwJX8+XGVPjjiOA54aD74iS2L0cYcTQ@mail.gmail.com>
     [not found]     ` <CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
2017-04-01 13:26       ` Natanael
2017-03-29 19:50 Raystonn .
2017-03-30 10:34 ` Tom Zander
2017-03-30 11:19   ` David Vorick
2017-03-30 21:42     ` Jared Lee Richardson
2017-03-30 11:24   ` Aymeric Vitte
2017-03-28 19:56 Paul Iverson
2017-03-28 20:16 ` Pieter Wuille
2017-03-28 20:43 ` Tom Zander
2017-03-28 20:53   ` Alphonse Pace
2017-03-28 21:06     ` Luke Dashjr
2017-03-28 16:59 Wang Chun
2017-03-28 17:13 ` Matt Corallo
2017-03-29  8:45   ` Jared Lee Richardson
2017-03-28 17:23 ` Alphonse Pace
2017-03-28 17:31   ` Wang Chun
2017-03-28 17:33     ` Jeremy
2017-03-28 17:50     ` Douglas Roark
2017-03-28 17:33   ` Juan Garavaglia
2017-03-28 17:53     ` Alphonse Pace
2017-03-28 22:36       ` Juan Garavaglia
2017-03-29  2:59         ` Luv Khemani
2017-03-29  6:24         ` Emin Gün Sirer
2017-03-29 15:34           ` Johnson Lau
2017-04-01 16:15             ` Leandro Coutinho
2017-03-29  9:16       ` Jared Lee Richardson
2017-03-29 16:00         ` Aymeric Vitte
2017-03-28 17:34 ` Johnson Lau
2017-03-28 17:46   ` Luke Dashjr
2017-03-28 20:50   ` Tom Zander
2017-03-29  4:21     ` Johnson Lau
2017-03-28 20:48 ` Tom Zander
2017-03-29  6:32 ` Bram Cohen
2017-03-29  9:37   ` Jorge Timón
2017-03-29 19:07     ` Jared Lee Richardson
2017-04-02 19:02       ` Staf Verhaegen
2017-03-29  7:49 ` Martin Lízner
2017-03-29 15:57   ` David Vorick
2017-03-29 16:08     ` Aymeric Vitte
     [not found]       ` <CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
2017-03-29 16:18         ` David Vorick
2017-03-29 16:20           ` Andrew Johnson
2017-03-29 16:25             ` David Vorick
2017-03-29 16:41               ` Andrew Johnson
2017-03-29 17:14                 ` Aymeric Vitte
2017-03-29 20:53               ` Jared Lee Richardson
2017-03-29 20:32           ` Jared Lee Richardson
2017-03-29 21:36             ` praxeology_guy
2017-03-29 22:33             ` Aymeric Vitte
2017-03-30  5:23               ` Ryan J Martin
2017-03-30 10:30                 ` Tom Zander
2017-03-30 16:44                   ` Jared Lee Richardson
2017-03-30 20:51                   ` Jared Lee Richardson
2017-03-30 21:57                     ` Tom Zander
     [not found]               ` <CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
2017-03-30 10:13                 ` Aymeric Vitte
2017-03-29 19:46     ` Jared Lee Richardson
2017-03-29 19:10   ` Jared Lee Richardson
2017-03-29 19:36     ` praxeology_guy
2017-04-02 19:12     ` Staf Verhaegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD1TkXsv3cu4w-vEJ5=jPxFC6EHr0ryGNy5ao3RrDNDCn5xELQ@mail.gmail.com' \
    --to=jaredr26@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=peter_r@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox