public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph•org>
To: Chris Priest <cp368202@ohiou•edu>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
Date: Sun, 13 Dec 2015 09:24:57 +0000	[thread overview]
Message-ID: <CAAS2fgQF769ds2F-mcOJ+-5gya-9qW_xcPdGimFE_1SJLmKV=A@mail.gmail.com> (raw)
In-Reply-To: <CAAcC9ysovzcm1SD_4XyxxofmwdXrcQqs0ckQBw626vYsdPftKw@mail.gmail.com>

On Sun, Dec 13, 2015 at 9:17 AM, Chris Priest <cp368202@ohiou•edu> wrote:
>> In none of these cases do you lose anything.
>
> Nor do you gain anything. Archive nodes will still need to exist

Not every node is an archive node; that's even the case today.
Lowering the resource requirements to independently enforce the rules
of the system is highly virtuous.

> precisely because paper wallets don't include UTXO data. This is like
> adding the ability to partially seed a movie with bittorrent.
[...]
> Every paper wallet would have to be re-printed with UTXO data

They are not printed now with UTXO data
(txid:vout:scriptpubkey:amount), and unless you start and fully
synchronize (or are running a full node) you already cannot author a
transaction without that data. The private key is already not enough,
and no Bitcoin node will just give you what you need to know.

The only additional information JL2012's scheme would add would be the
hash tree fragments to show membership; and the same places that
currently give you what is required to author a transaction could
provide it for you.

> included. It doesn't even solve the core problem because someone can
> still flood the network with lots of UTXOs, as long as they spend them
> quickly.

The system already inhibits the rate new UTXO can be added; but we're
still left with the perpetually growing history that contains many
lost and otherwise unspendable outputs.


  reply	other threads:[~2015-12-13  9:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12 20:09 jl2012
2015-12-12 23:01 ` gb
2015-12-13  1:00   ` Vincent Truong
2015-12-13  2:07     ` Gregory Maxwell
2015-12-13  8:13       ` Chris Priest
2015-12-13  8:18         ` Gregory Maxwell
2015-12-13  9:17           ` Chris Priest
2015-12-13  9:24             ` Gregory Maxwell [this message]
2015-12-13 18:11             ` jl2012
2015-12-13 21:20               ` Ricardo Filipe
2015-12-13 21:36               ` Tier Nolan
2015-12-20 11:24       ` Peter Todd
2015-12-20 11:34         ` Jeff Garzik
2015-12-20 11:43           ` s7r
2015-12-20 16:30           ` Chris Pacia
2015-12-20 16:35             ` Peter Todd
2015-12-21  3:34               ` Jeff Garzik
2015-12-21  3:23           ` Tom Harding
2015-12-13 16:14 ` Danny Thorpe

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='CAAS2fgQF769ds2F-mcOJ+-5gya-9qW_xcPdGimFE_1SJLmKV=A@mail.gmail.com' \
    --to=greg@xiph$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=cp368202@ohiou$(echo .)edu \
    /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