From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mark Friedenbach <mark@monetize•io>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Date: Tue, 4 Dec 2012 14:36:39 -0500 [thread overview]
Message-ID: <CAAS2fgSGa3HJcZVi1QS8qpsypvtxhLLZmAseVyx9UkbRPh36CA@mail.gmail.com> (raw)
In-Reply-To: <CACh7GpHUE2CYAMfRdAVPv1WAk102z94KYCWPV87fzzQEaP_hfw@mail.gmail.com>
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach <mark@monetize•io> wrote:
> Alan's
:(
> UTxO meta-chain proposal becomes vastly easier to do now that
> ultraprune is merged.
No, not really. Somewhat easier due to some structural changes, but it
still needs to invent and get consensus on a normative data structure
and people need to write implementations of the required operations on
it (implementations probably required to prove performance for
consensus). We still have to sort through the tradeoff of making a
_single_ data structure the normative merkle tree representation for
the UTxO set to the preclusion of other implementations— including
ones which are asymptotically faster, such as a straight hash table.
There are also issues that need to be sorted out like key structure—
the most useful index for validation is txid:vout keyed, but Alan
wanted 'address' prefixed, which is not friendly for validation but
enables robust query by address— a query that the referce normal
bitcoin software doesn't even optionally support right now. Any
disagreements on this point must be hammed out because the structure
would be normative.
> That would allow the Satoshi client to know it's
> wallet balance and operate with a >=SPV level of security during the initial
> block download, and keep them on the path of becoming a full node. If users
> can see their balances, send and receive transactions, and otherwise go
> about their business (except for mining) during the initial block download,
> would that not address your concerns?
The above said, that is all good stuff too. And I do thing starting
fast with reduced security (be it to SPV+ or SPV) is a good idea.
next prev parent reply other threads:[~2012-12-04 19:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 17:46 Mike Hearn
2012-12-04 18:03 ` Alan Reiner
2012-12-04 18:08 ` Will
2012-12-04 18:17 ` Gregory Maxwell
2012-12-04 20:58 ` Mike Hearn
2012-12-04 21:41 ` Gregory Maxwell
2012-12-04 22:44 ` Alan Reiner
2012-12-05 0:27 ` Gregory Maxwell
2012-12-05 2:08 ` Alan Reiner
2012-12-05 2:54 ` Gregory Maxwell
2012-12-05 5:38 ` Jim Nguyen
2012-12-05 7:50 ` Wladimir
2012-12-05 9:43 ` Gary Rowe
2012-12-05 10:19 ` Robert Backhaus
2012-12-05 10:43 ` Mike Hearn
2012-12-04 18:57 ` Mark Friedenbach
2012-12-04 19:36 ` Gregory Maxwell [this message]
[not found] <mailman.70419.1354648162.2176.bitcoin-development@lists.sourceforge.net>
2012-12-04 19:56 ` Jim
2012-12-04 22:23 ` slush
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=CAAS2fgSGa3HJcZVi1QS8qpsypvtxhLLZmAseVyx9UkbRPh36CA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mark@monetize$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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