public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Gronager <gronager@ceptacle.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: "bitcoin-development@lists.sourceforge.net Dev"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Date: Mon, 11 Mar 2013 22:15:23 +0100	[thread overview]
Message-ID: <D80BAE2B-4F2B-4ADF-A8C4-E57CBCEEC470@ceptacle.com> (raw)
In-Reply-To: <CAAS2fgRJznqyFuWnhHedA151peVn4K77Bw82ACC1WhnUyCdAqw@mail.gmail.com>

>> The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared.
> 
> I believe you are confusing disjoint things.

Nope, ahh well, I agree that the use of UTXOs in the Satoshi client today by no means a directed towards a DHT, though it does help speeding up validation (db lookup to check if an output is indeed unspent).

However, an alternative way to bootstrap and validate transactions exist, needing only the UTXOs and not the rest of the blockchain history: An authenticated data structure storing the UTXOs in a DHT. 

/M


> 
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
> endpoint security space. For insight on selecting the right partner to 
> tackle endpoint security challenges, access the full report. 
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development




  reply	other threads:[~2013-03-11 21:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-10  4:31 [Bitcoin-development] Blocking uneconomical UTXO creation Peter Todd
2013-03-11 11:01 `  Jorge Timón
2013-03-11 15:36   ` Gavin Andresen
2013-03-11 16:45     `  Jorge Timón
2013-03-11 16:46       `  Jorge Timón
2013-03-11 16:54         ` Mike Hearn
2013-03-11 17:08           `  Jorge Timón
2013-03-11 18:17           ` Benjamin Lindner
2013-03-11 18:59             ` Mark Friedenbach
2013-03-11 18:59             `  Jorge Timón
2013-03-11 19:08             ` Tadas Varanavičius
2013-03-11 22:19               ` Mike Hearn
2013-03-11 22:25                 ` Tadas Varanavičius
2013-03-11 22:39                   ` Mike Hearn
2013-03-11 23:26                     ` Tadas Varanavičius
2013-03-11 17:18     ` Jeff Garzik
2013-03-11 20:08   ` Rune Kjær Svendsen
2013-03-11 20:36     ` Michael Gronager
2013-03-11 21:01       ` Gregory Maxwell
2013-03-11 21:15         ` Michael Gronager [this message]
2013-03-12  7:49 ` Peter Todd
2013-03-13  5:31   ` Stephen Pair
2013-03-13  9:20     `  Jorge Timón

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=D80BAE2B-4F2B-4ADF-A8C4-E57CBCEEC470@ceptacle.com \
    --to=gronager@ceptacle.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gmaxwell@gmail.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