* [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
@ 2015-12-12 20:09 jl2012
2015-12-12 23:01 ` gb
2015-12-13 16:14 ` Danny Thorpe
0 siblings, 2 replies; 19+ messages in thread
From: jl2012 @ 2015-12-12 20:09 UTC (permalink / raw)
To: bitcoin-dev
It is a common practice in commercial banks that a dormant account might
be confiscated. Confiscating or deleting dormant UTXOs might be too
controversial, but allowing the UTXOs set growing without any limit
might not be a sustainable option. People lose their private keys.
People do stupid things like sending bitcoin to 1BitcoinEater. We
shouldn’t be obliged to store everything permanently. This is my
proposal:
Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
X after 420000, it will commit to a hash for all UTXOs generated in
block X-420000. The UTXOs are first serialized into the form:
txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
After some confirmations, nodes may safely delete the UTXO records of
block X permanently.
If a user is trying to redeem a dormant UTXO, in addition the signature,
they have to provide the scriptPubKey, height (X), and UTXO value as
part of the witness. They also need to provide the Merkle path to the
dormant UTXO commitment.
To confirm this tx, the miner will calculate a new Merkle hash for the
block X, with the hash of the spent UTXO replaced by 1, and commit the
hash to the current block. All full nodes will keep an index of latest
dormant UTXO commitments so double spending is not possible. (a
"meta-UTXO set")
If all dormant UTXOs under a Merkle branch are spent, hash of the branch
will become 1. If all dormant UTXOs in a block are spent, the record for
this block could be forgotten. Full nodes do not need to remember which
particular UTXO is spent or not, since any person trying to redeem a
dormant UTXO has to provide such information.
It becomes the responsibility of dormant coin holders to scan the
blockchain for the current status of the UTXO commitment for their coin.
They may also need to pay extra fee for the increased tx size.
This is a softfork if there is no hash collision but this is a
fundamental assumption in Bitcoin anyway. The proposal also works
without segregated witness, just by replacing "witness" with "scriptSig"
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-12 20:09 [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin jl2012
@ 2015-12-12 23:01 ` gb
2015-12-13 1:00 ` Vincent Truong
2015-12-13 16:14 ` Danny Thorpe
1 sibling, 1 reply; 19+ messages in thread
From: gb @ 2015-12-12 23:01 UTC (permalink / raw)
To: jl2012; +Cc: bitcoin-dev
The general concept has merit and the basic outline here seems sound
enough. I have harboured a notion for having "archived UTXO" for some
time, this is essentially it. The retrieval from archive cost is on the
UTXO holder not the entire storage network, which is then only bearing
full 'instant' retrieval costs for N blocks.
On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:
> It is a common practice in commercial banks that a dormant account might
> be confiscated. Confiscating or deleting dormant UTXOs might be too
> controversial, but allowing the UTXOs set growing without any limit
> might not be a sustainable option. People lose their private keys.
> People do stupid things like sending bitcoin to 1BitcoinEater. We
> shouldn’t be obliged to store everything permanently. This is my
> proposal:
>
> Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
> X after 420000, it will commit to a hash for all UTXOs generated in
> block X-420000. The UTXOs are first serialized into the form:
> txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> After some confirmations, nodes may safely delete the UTXO records of
> block X permanently.
>
> If a user is trying to redeem a dormant UTXO, in addition the signature,
> they have to provide the scriptPubKey, height (X), and UTXO value as
> part of the witness. They also need to provide the Merkle path to the
> dormant UTXO commitment.
>
> To confirm this tx, the miner will calculate a new Merkle hash for the
> block X, with the hash of the spent UTXO replaced by 1, and commit the
> hash to the current block. All full nodes will keep an index of latest
> dormant UTXO commitments so double spending is not possible. (a
> "meta-UTXO set")
>
> If all dormant UTXOs under a Merkle branch are spent, hash of the branch
> will become 1. If all dormant UTXOs in a block are spent, the record for
> this block could be forgotten. Full nodes do not need to remember which
> particular UTXO is spent or not, since any person trying to redeem a
> dormant UTXO has to provide such information.
>
> It becomes the responsibility of dormant coin holders to scan the
> blockchain for the current status of the UTXO commitment for their coin.
> They may also need to pay extra fee for the increased tx size.
>
> This is a softfork if there is no hash collision but this is a
> fundamental assumption in Bitcoin anyway. The proposal also works
> without segregated witness, just by replacing "witness" with "scriptSig"
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-12 23:01 ` gb
@ 2015-12-13 1:00 ` Vincent Truong
2015-12-13 2:07 ` Gregory Maxwell
0 siblings, 1 reply; 19+ messages in thread
From: Vincent Truong @ 2015-12-13 1:00 UTC (permalink / raw)
To: gb; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4653 bytes --]
Dormant threshold is way too low. There's many news articles about people
forgetting that they used to mine bitcoins and then suddenly remembered.
This will continue to happen for much longer than 8 years as people
rediscover bitcoin when it goes further mainstream. You can't expect them
to have run a node/kept their utxo before they were aware of this change
and then realise miners have discarded their utxo. Oops?
Since we can't predict when mainstream will happen, you instead need a
threshold where the key holder is likely dead. That should be like 80 years
or 120 years, so 4.2m to 6.3m confirmations.
Next paragraph is off topic:
IMO it would be even better for these dormant & dead key holder's utxos to
also re-enter the economy as miner fees; let 1 dormant utxo to be mined per
block. It would need a hard fork. But then maybe people would stop being so
stupid with burning bitcoins/sending it to 1BitcoinEater, or mining a
million bitcoins from day 1 and leaving it, if they know it'll eventually
go into another miner's pockets. This could be used to fund cheap
transactions forever, and miners would be incentivised to hold copies of
these dormant utxos since it could become theirs one day. But this would be
even more controversial than just expiring them as we are in no short
supply of people who believe in Bitcoin's deflationary, fossil fuel
(burnable) economy, rather than a cyclical economy that better resembles
how we treat lost gold today...
On Dec 13, 2015 10:29 AM, "gb via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> The general concept has merit and the basic outline here seems sound
> enough. I have harboured a notion for having "archived UTXO" for some
> time, this is essentially it. The retrieval from archive cost is on the
> UTXO holder not the entire storage network, which is then only bearing
> full 'instant' retrieval costs for N blocks.
>
> On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:
> > It is a common practice in commercial banks that a dormant account might
> > be confiscated. Confiscating or deleting dormant UTXOs might be too
> > controversial, but allowing the UTXOs set growing without any limit
> > might not be a sustainable option. People lose their private keys.
> > People do stupid things like sending bitcoin to 1BitcoinEater. We
> > shouldn’t be obliged to store everything permanently. This is my
> > proposal:
> >
> > Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
> > X after 420000, it will commit to a hash for all UTXOs generated in
> > block X-420000. The UTXOs are first serialized into the form:
> > txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> > After some confirmations, nodes may safely delete the UTXO records of
> > block X permanently.
> >
> > If a user is trying to redeem a dormant UTXO, in addition the signature,
> > they have to provide the scriptPubKey, height (X), and UTXO value as
> > part of the witness. They also need to provide the Merkle path to the
> > dormant UTXO commitment.
> >
> > To confirm this tx, the miner will calculate a new Merkle hash for the
> > block X, with the hash of the spent UTXO replaced by 1, and commit the
> > hash to the current block. All full nodes will keep an index of latest
> > dormant UTXO commitments so double spending is not possible. (a
> > "meta-UTXO set")
> >
> > If all dormant UTXOs under a Merkle branch are spent, hash of the branch
> > will become 1. If all dormant UTXOs in a block are spent, the record for
> > this block could be forgotten. Full nodes do not need to remember which
> > particular UTXO is spent or not, since any person trying to redeem a
> > dormant UTXO has to provide such information.
> >
> > It becomes the responsibility of dormant coin holders to scan the
> > blockchain for the current status of the UTXO commitment for their coin.
> > They may also need to pay extra fee for the increased tx size.
> >
> > This is a softfork if there is no hash collision but this is a
> > fundamental assumption in Bitcoin anyway. The proposal also works
> > without segregated witness, just by replacing "witness" with "scriptSig"
> >
> > _______________________________________________
> > 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: 5602 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 1:00 ` Vincent Truong
@ 2015-12-13 2:07 ` Gregory Maxwell
2015-12-13 8:13 ` Chris Priest
2015-12-20 11:24 ` Peter Todd
0 siblings, 2 replies; 19+ messages in thread
From: Gregory Maxwell @ 2015-12-13 2:07 UTC (permalink / raw)
To: Vincent Truong; +Cc: Bitcoin Dev
On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> have run a node/kept their utxo before they were aware of this change and
> then realise miners have discarded their utxo. Oops?
I believe you have misunderstood jl2012's post. His post does not
cause the outputs to become discarded. They are still spendable,
but the transactions must carry a membership proof to spend them.
They don't have to have stored the data themselves, but they must
get it from somewhere-- including archive nodes that serve this
purpose rather than having every full node carry all that data forever.
Please be conservative with the send button. The list loses its
utility if every moderately complex idea is hit with reflexive
opposition by people who don't understand it.
Peter Todd has proposed something fairly similar with "STXO
commitments". The primary argument against this kind of approach that
I'm aware of is that the membership proofs get pretty big, and if too
aggressive this trades bandwidth for storage, and storage is usually
the cheaper resource. Though at least the membership proofs could be
omitted when transmitting to a node which has signaled that it has
kept the historical data anyways.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 2:07 ` Gregory Maxwell
@ 2015-12-13 8:13 ` Chris Priest
2015-12-13 8:18 ` Gregory Maxwell
2015-12-20 11:24 ` Peter Todd
1 sibling, 1 reply; 19+ messages in thread
From: Chris Priest @ 2015-12-13 8:13 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
I don't like this scheme at all. It doesn't seem to make bitcoin
better, it makes it worse.
Lets say it's 2050 and I want to sweep a paper wallet I created in
2013. I can't just make the TX and send it to the network, I have to
first contact an "archive node" to get the UTXO data in order to make
the TX. How is this better than how the system works today?
Since many people are going to be holding BTC long term (store of
value of a first-class feature of bitcoin), this scheme is going to
effect pretty much all users.
These archive nodes will be essential to network's operation. If there
are no running archive nodes, the effect on the network is the same as
the network today without any full nodes.
Anyways, UTXO size is a function of number of users, rather than a
function of time. If tons of people join the network, UTXO still will
increase no matter what. All this change is going to do is make it
harder for people to use bitcoin. A person can still generate 1GB of
UTXO data, but as long as they spend those UTXOs within the amount
they are still using those resources.
IMO, wildcard inputs is still the best way to limit the UTXO set.
On 12/12/15, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> have run a node/kept their utxo before they were aware of this change and
>> then realise miners have discarded their utxo. Oops?
>
> I believe you have misunderstood jl2012's post. His post does not
> cause the outputs to become discarded. They are still spendable,
> but the transactions must carry a membership proof to spend them.
> They don't have to have stored the data themselves, but they must
> get it from somewhere-- including archive nodes that serve this
> purpose rather than having every full node carry all that data forever.
>
> Please be conservative with the send button. The list loses its
> utility if every moderately complex idea is hit with reflexive
> opposition by people who don't understand it.
>
> Peter Todd has proposed something fairly similar with "STXO
> commitments". The primary argument against this kind of approach that
> I'm aware of is that the membership proofs get pretty big, and if too
> aggressive this trades bandwidth for storage, and storage is usually
> the cheaper resource. Though at least the membership proofs could be
> omitted when transmitting to a node which has signaled that it has
> kept the historical data anyways.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 8:13 ` Chris Priest
@ 2015-12-13 8:18 ` Gregory Maxwell
2015-12-13 9:17 ` Chris Priest
0 siblings, 1 reply; 19+ messages in thread
From: Gregory Maxwell @ 2015-12-13 8:18 UTC (permalink / raw)
To: Chris Priest; +Cc: Bitcoin Dev
On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest <cp368202@ohiou•edu> wrote:
> Lets say it's 2050 and I want to sweep a paper wallet I created in
> 2013. I can't just make the TX and send it to the network, I have to
> first contact an "archive node" to get the UTXO data in order to make
> the TX. How is this better than how the system works today?
You already are in that boat. If your paper wallet has only the
private key (as 100% of them do today). You'll have no idea what coins
have been assigned to it, or what their TXids are. You'll need to
contact a public index (which isn't a service existing nodes provide)
or synchronize the full blockchain history to find it. Both are also
sufficient for jl2012's (/Petertodd's STXO), they'd only be providing
you with somewhat more data. If instead, you insist that you'd
already be running a full node and not have to wait for the sync, then
again you'd also be your own archive. In none of these cases do you
lose anything.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 8:18 ` Gregory Maxwell
@ 2015-12-13 9:17 ` Chris Priest
2015-12-13 9:24 ` Gregory Maxwell
2015-12-13 18:11 ` jl2012
0 siblings, 2 replies; 19+ messages in thread
From: Chris Priest @ 2015-12-13 9:17 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
> In none of these cases do you lose anything.
Nor do you gain anything. Archive nodes will still need to exist
precisely because paper wallets don't include UTXO data. This is like
adding the ability to partially seed a movie with bittorrent. You
still need someone who has the whole thing has to be participating in
order for anyone to play the movie.
This isn't going to kill bitcoin, but it won't make it any better.
Every paper wallet would have to be re-printed with UTXO data
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.
On 12/13/15, Gregory Maxwell <greg@xiph•org> wrote:
> On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest <cp368202@ohiou•edu> wrote:
>> Lets say it's 2050 and I want to sweep a paper wallet I created in
>> 2013. I can't just make the TX and send it to the network, I have to
>> first contact an "archive node" to get the UTXO data in order to make
>> the TX. How is this better than how the system works today?
>
> You already are in that boat. If your paper wallet has only the
> private key (as 100% of them do today). You'll have no idea what coins
> have been assigned to it, or what their TXids are. You'll need to
> contact a public index (which isn't a service existing nodes provide)
> or synchronize the full blockchain history to find it. Both are also
> sufficient for jl2012's (/Petertodd's STXO), they'd only be providing
> you with somewhat more data. If instead, you insist that you'd
> already be running a full node and not have to wait for the sync, then
> again you'd also be your own archive. In none of these cases do you
> lose anything.
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 9:17 ` Chris Priest
@ 2015-12-13 9:24 ` Gregory Maxwell
2015-12-13 18:11 ` jl2012
1 sibling, 0 replies; 19+ messages in thread
From: Gregory Maxwell @ 2015-12-13 9:24 UTC (permalink / raw)
To: Chris Priest; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-12 20:09 [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin jl2012
2015-12-12 23:01 ` gb
@ 2015-12-13 16:14 ` Danny Thorpe
1 sibling, 0 replies; 19+ messages in thread
From: Danny Thorpe @ 2015-12-13 16:14 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
What is the current behavior / cost that this proposal is trying to avoid?
Are ancient utxos required to be kept in memory always in a fully
validating node, or can ancient utxos get pushed out of memory like a
normal LRU caching db?
Thanks,
-Danny
On Dec 12, 2015 1:55 PM, "jl2012--- via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> It is a common practice in commercial banks that a dormant account might
> be confiscated. Confiscating or deleting dormant UTXOs might be too
> controversial, but allowing the UTXOs set growing without any limit might
> not be a sustainable option. People lose their private keys. People do
> stupid things like sending bitcoin to 1BitcoinEater. We shouldn’t be
> obliged to store everything permanently. This is my proposal:
>
> Dormant UTXOs are those UTXOs with 420000 confirmations. In every block X
> after 420000, it will commit to a hash for all UTXOs generated in block
> X-420000. The UTXOs are first serialized into the form:
> txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> After some confirmations, nodes may safely delete the UTXO records of block
> X permanently.
>
> If a user is trying to redeem a dormant UTXO, in addition the signature,
> they have to provide the scriptPubKey, height (X), and UTXO value as part
> of the witness. They also need to provide the Merkle path to the dormant
> UTXO commitment.
>
> To confirm this tx, the miner will calculate a new Merkle hash for the
> block X, with the hash of the spent UTXO replaced by 1, and commit the hash
> to the current block. All full nodes will keep an index of latest dormant
> UTXO commitments so double spending is not possible. (a "meta-UTXO set")
>
> If all dormant UTXOs under a Merkle branch are spent, hash of the branch
> will become 1. If all dormant UTXOs in a block are spent, the record for
> this block could be forgotten. Full nodes do not need to remember which
> particular UTXO is spent or not, since any person trying to redeem a
> dormant UTXO has to provide such information.
>
> It becomes the responsibility of dormant coin holders to scan the
> blockchain for the current status of the UTXO commitment for their coin.
> They may also need to pay extra fee for the increased tx size.
>
> This is a softfork if there is no hash collision but this is a fundamental
> assumption in Bitcoin anyway. The proposal also works without segregated
> witness, just by replacing "witness" with "scriptSig"
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3174 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 9:17 ` Chris Priest
2015-12-13 9:24 ` Gregory Maxwell
@ 2015-12-13 18:11 ` jl2012
2015-12-13 21:20 ` Ricardo Filipe
2015-12-13 21:36 ` Tier Nolan
1 sibling, 2 replies; 19+ messages in thread
From: jl2012 @ 2015-12-13 18:11 UTC (permalink / raw)
To: Chris Priest; +Cc: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe@gmail•com>
wrote:
> What is the current behavior / cost that this proposal is trying to
> avoid? Are ancient utxos required to be kept in memory always in a
> fully validating node, or can ancient utxos get pushed out of memory
> like a normal LRU caching db?
I don't see why it must be kept in memory. But storage is still a
problem. With the 8 year limit and a fixed max block size, it indirectly
sets an upper limit for UTXO set.
Chris Priest via bitcoin-dev :
> This isn't going to kill bitcoin, but it won't make it any better.
Do you believe that thousands of volunteer full nodes are obliged to
store an UTXO record, just because one paid US$0.01 to an anonymous
miner 100 years ago? It sounds insanely cheap, isn't it? My proposal (or
similar proposal by Peter Todd) is to solve this problem. Many
commercial banks have a dormant threshold less than 8 years so I believe
it is a balanced choice.
Back to the topic, I would like to further elaborate my proposal.
We have 3 types of full nodes:
Archive nodes: full nodes that store the whole blockchain
Full UTXO nodes: full nodes that fully store the latest UTXO state, but
not the raw blockchain
Lite UTXO nodes: full nodes that store only UTXO created in that past
420000 blocks
Currently, if one holds nothing but a private key, he must consult
either an archive node or a full UTXO node for the latest UTXO state to
spend his coin. We currently do not have any lite UTXO node, and such
node would not work properly beyond block 420000.
With the softfork I described in my original post, if the UTXO is
created within the last 420000 blocks, the key holder may consult any
type of full node, including a lite UTXO node, to create the
transaction.
If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO
node obviously can't provide the necessary information to spend the
coin. However, not even a full UTXO node may do so. A full UTXO node
could tell the position of the UTXO in the blockchain, but can't provide
all the information required by my specification. Only an archive node
may do so.
What extra information is needed?
(1) If your UTXO was generated in block Y, you first need to know the
TXO state (spent / unspent) of all outputs in block Y at block (Y +
420000). Only UTXOs at that time are relevant.
(2) You also need to know if there was any spending of any block Y UTXOs
after block (Y + 420000).
It is not possible to construct the membership prove I require without
these information. It is designed this way, so that lite UTXO nodes
won't need to store any dormant UTXO records: not even the hash of
individual dormant UTXO records. If the blockchain grows to insanely
big, it may take days or weeks to retrieve to records. However, I don't
think this is relevant as one has already left his coins dormant for >8
years. Actually, you don't even need the full blockchain. For (1), all
you need is the 420000 blocks from Y to Y+420000 minus any witness data,
as you don't need to do any validation. For (2), you just need the
coinbase of Y+420001 to present, where any spending would have been
committed, and retrieve the full block only if a spending is found.
So the Bitcoin Bank (miners) is not going to shred your record and
confiscate your money. Instead, the Bank throws your record to the
garage (raw blockchain). You can search for your record by yourself, or
employ someone (archive node) to search it for you. In any case it
incurs costs. But as thousands of bankers have kept your record on their
limited desk space for 8 years for free (though one of them might
receive a fraction of a penny from you), you shouldn't complain with any
moral, technical, or legal reason. And no matter what users say, I
believe something like this will happen when miners and full nodes can't
handle the UTXO set.
I'd like to see more efficient proposals that archive the same goals.
p.s. there were some typos in my original. The second sentence of the
second paragraph should be read as "For every block X+420000, it will
commit to a hash for all UTXOs generated in block X."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV
Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3
DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9
Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A
PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8
lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS
VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93
zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V
EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ==
=2xRy
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 18:11 ` jl2012
@ 2015-12-13 21:20 ` Ricardo Filipe
2015-12-13 21:36 ` Tier Nolan
1 sibling, 0 replies; 19+ messages in thread
From: Ricardo Filipe @ 2015-12-13 21:20 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5766 bytes --]
I really like ideas that tackle this issue. The question imho is what is
the incentive to run a "Full UTXO node" instead of a pruned or archive node.
For starters, it would be nice to know what would be the savings for Full
UTXO nodes over archive nodes right now.
Also, what advantages would this have over "archive pruned nodes: nodes
that store X blocks of the whole blockchain before 420000". Seems like an
interesting intermediate use case to me too.
2015-12-13 18:11 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe@gmail•com>
> wrote:
>
>> What is the current behavior / cost that this proposal is trying to
>> avoid? Are ancient utxos required to be kept in memory always in a fully
>> validating node, or can ancient utxos get pushed out of memory like a
>> normal LRU caching db?
>>
>
> I don't see why it must be kept in memory. But storage is still a problem.
> With the 8 year limit and a fixed max block size, it indirectly sets an
> upper limit for UTXO set.
>
>
> Chris Priest via bitcoin-dev :
>
>> This isn't going to kill bitcoin, but it won't make it any better.
>>
>
> Do you believe that thousands of volunteer full nodes are obliged to store
> an UTXO record, just because one paid US$0.01 to an anonymous miner 100
> years ago? It sounds insanely cheap, isn't it? My proposal (or similar
> proposal by Peter Todd) is to solve this problem. Many commercial banks
> have a dormant threshold less than 8 years so I believe it is a balanced
> choice.
>
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 420000 blocks
>
> Currently, if one holds nothing but a private key, he must consult either
> an archive node or a full UTXO node for the latest UTXO state to spend his
> coin. We currently do not have any lite UTXO node, and such node would not
> work properly beyond block 420000.
>
> With the softfork I described in my original post, if the UTXO is created
> within the last 420000 blocks, the key holder may consult any type of full
> node, including a lite UTXO node, to create the transaction.
>
> If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO
> node obviously can't provide the necessary information to spend the coin.
> However, not even a full UTXO node may do so. A full UTXO node could tell
> the position of the UTXO in the blockchain, but can't provide all the
> information required by my specification. Only an archive node may do so.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 420000).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 420000).
>
> It is not possible to construct the membership prove I require without
> these information. It is designed this way, so that lite UTXO nodes won't
> need to store any dormant UTXO records: not even the hash of individual
> dormant UTXO records. If the blockchain grows to insanely big, it may take
> days or weeks to retrieve to records. However, I don't think this is
> relevant as one has already left his coins dormant for >8 years. Actually,
> you don't even need the full blockchain. For (1), all you need is the
> 420000 blocks from Y to Y+420000 minus any witness data, as you don't need
> to do any validation. For (2), you just need the coinbase of Y+420001 to
> present, where any spending would have been committed, and retrieve the
> full block only if a spending is found.
>
> So the Bitcoin Bank (miners) is not going to shred your record and
> confiscate your money. Instead, the Bank throws your record to the garage
> (raw blockchain). You can search for your record by yourself, or employ
> someone (archive node) to search it for you. In any case it incurs costs.
> But as thousands of bankers have kept your record on their limited desk
> space for 8 years for free (though one of them might receive a fraction of
> a penny from you), you shouldn't complain with any moral, technical, or
> legal reason. And no matter what users say, I believe something like this
> will happen when miners and full nodes can't handle the UTXO set.
>
> I'd like to see more efficient proposals that archive the same goals.
>
> p.s. there were some typos in my original. The second sentence of the
> second paragraph should be read as "For every block X+420000, it will
> commit to a hash for all UTXOs generated in block X."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV
> Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3
> DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9
> Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A
> PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8
> lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS
> VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93
> zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V
> EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ==
> =2xRy
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7069 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 18:11 ` jl2012
2015-12-13 21:20 ` Ricardo Filipe
@ 2015-12-13 21:36 ` Tier Nolan
1 sibling, 0 replies; 19+ messages in thread
From: Tier Nolan @ 2015-12-13 21:36 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
On Sun, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 420000 blocks
>
There is a risk that miners would eventually react by just refusing to
accept blocks that spend dormant outputs. This is a risk even without the
protocol, but I think if there are already lots of UTXO-lite nodes
deployed, it would be much easier to just define them as the new
(soft-forked) consensus rule.
There is a precedent for things to be disabled rather than fixed when
security problems arise.
Imagine a crisis caused by a security related bug with the revival proofs.
Disabling them is much lower risk than trying to find/fix the bug and then
deploy the fix. The longer it takes, the longer the security problem
remains.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 420000).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 420000).
>
Is this how it works?
Source transaction is included in block Y.
If the output is spent before Y + 420,000, then no further action is taken.
The miner for block Y + 420,000 will include a commitment to
merkle_hash(Block Y's unspent outputs).
It is possible for someone to prove that they didn't spend their
transaction before Y + 420,000.
I think the miners have to remember the "live" UTXO merkle root for every
block?
With the path to the UTXO and the miner can recalculate the root for that
block.
If there were 20 dormant outputs being spent, then the miner would have to
commit to 20 updates.
[-- Attachment #2: Type: text/html, Size: 2760 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-13 2:07 ` Gregory Maxwell
2015-12-13 8:13 ` Chris Priest
@ 2015-12-20 11:24 ` Peter Todd
2015-12-20 11:34 ` Jeff Garzik
1 sibling, 1 reply; 19+ messages in thread
From: Peter Todd @ 2015-12-20 11:24 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]
On Sun, Dec 13, 2015 at 02:07:36AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > have run a node/kept their utxo before they were aware of this change and
> > then realise miners have discarded their utxo. Oops?
>
> I believe you have misunderstood jl2012's post. His post does not
> cause the outputs to become discarded. They are still spendable,
> but the transactions must carry a membership proof to spend them.
> They don't have to have stored the data themselves, but they must
> get it from somewhere-- including archive nodes that serve this
> purpose rather than having every full node carry all that data forever.
>
> Please be conservative with the send button. The list loses its
> utility if every moderately complex idea is hit with reflexive
> opposition by people who don't understand it.
>
> Peter Todd has proposed something fairly similar with "STXO
> commitments". The primary argument against this kind of approach that
That's incorrect terminology - what I proposed are "TXO commitments". I
proposed that a MMR of all prior transaction outputs's, spent and
unspent, be committed too in blocks along with a spentness flag, not
just spent transaction outputs.
That's why I often use the term (U)TXO commitments to refer to both
classes of proposals.
> I'm aware of is that the membership proofs get pretty big, and if too
> aggressive this trades bandwidth for storage, and storage is usually
> the cheaper resource. Though at least the membership proofs could be
> omitted when transmitting to a node which has signaled that it has
> kept the historical data anyways.
What I proprosed is that a consensus-critical maximum UTXO age be part
of the protocol; UTXO's younger than that age are expected to be cached.
For UTXO's older than that age, they can be dropped from the cache,
however to spend them you are required to provide the proof, and that
proof counts as blockchain space to account for the fact that they do
need to be broadcast on the network.
The proofs are relatively large, but not so much larger than a CTxIn as
to make paying for that data infeasible.
--
'peter'[:-1]@petertodd.org
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-20 11:24 ` Peter Todd
@ 2015-12-20 11:34 ` Jeff Garzik
2015-12-20 11:43 ` s7r
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Jeff Garzik @ 2015-12-20 11:34 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]
On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.
Yes, this is almost what -has- to happen in the long term.
Ideally we should start having wallets generate those proofs now, and then
introduce the max-age as a second step as a planned hard fork a couple
years down the line.
However,
1) There is also the open question of "grandfathered" UTXOs - for those
wallets generated in 2009, buried in a landfill and then dug out 10 years
ago
2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
[-- Attachment #2: Type: text/html, Size: 1670 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-20 11:34 ` Jeff Garzik
@ 2015-12-20 11:43 ` s7r
2015-12-20 16:30 ` Chris Pacia
2015-12-21 3:23 ` Tom Harding
2 siblings, 0 replies; 19+ messages in thread
From: s7r @ 2015-12-20 11:43 UTC (permalink / raw)
To: Jeff Garzik, Peter Todd; +Cc: Bitcoin Dev
What will be the actual effect over wallets?
Say I have the private key for a dormant UTXO older than the
consensus-critical maximum UTXO age. The UTXO is not part of the cache.
So I setup a full node and import my old private key (wallet.dat). Will
I even see the correct balance (where will it get if from, since it's
dropped from the cache), or it will show me a 0 balance?
If I can see the correct balance, where can I get the proof I need and
what ensures I'll always be able to get that proof?
On 12/20/2015 1:34 PM, Jeff Garzik via bitcoin-dev wrote:
> On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.
>
>
> Yes, this is almost what -has- to happen in the long term.
>
> Ideally we should start having wallets generate those proofs now, and
> then introduce the max-age as a second step as a planned hard fork a
> couple years down the line.
>
> However,
> 1) There is also the open question of "grandfathered" UTXOs - for those
> wallets generated in 2009, buried in a landfill and then dug out 10
> years ago
>
> 2) This reverses the useful minimization attribute of HD wallets - "just
> backup the seed"
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
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:23 ` Tom Harding
2 siblings, 1 reply; 19+ messages in thread
From: Chris Pacia @ 2015-12-20 16:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
It would be nice if the bip37 filter matching algorithm was extended to
serve up the proof.
And if server-based wallets did the same it would preserve the "just backup
the seed" functionality.
[-- Attachment #2: Type: text/html, Size: 565 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-20 16:30 ` Chris Pacia
@ 2015-12-20 16:35 ` Peter Todd
2015-12-21 3:34 ` Jeff Garzik
0 siblings, 1 reply; 19+ messages in thread
From: Peter Todd @ 2015-12-20 16:35 UTC (permalink / raw)
To: Chris Pacia, Jeff Garzik; +Cc: bitcoin-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia <ctpacia@gmail•com> wrote:
>On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
>bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 2) This reverses the useful minimization attribute of HD wallets -
>"just
>backup the seed"
>
>It would be nice if the bip37 filter matching algorithm was extended to
>serve up the proof.
>
>And if server-based wallets did the same it would preserve the "just
>backup
>the seed" functionality.
Exactly! The information will be out there - "just backup the seed" requires someone to have the exact same data needed to generate the TXO-unspent proof that my proposal requires to spend an old txout.
tl;dr: jgarzik is incorrect; theres no difference at all from the status quo.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWdtjA
AAoJEMCF8hzn9Lncz4MH/iwwa7xlbrJJiYqe7Hccr3Vm5D/qbv60eYi2btPDHFo9
mRnijzqFtt60e1AoFr9NwnCrAhhGmYkWsxLcA2oF+38H12DS9qsb9oT+pckJX34V
v06+Uap89v9VTHcxVrOEQUCx+9xQO7WkpFw/OTZJA4nmFZ8lvbgDGWE9q7mjQKof
QU1FiOM7mI6QCU8xTjRvVX5pTwvYNB7PAie/UoCfWU7/QdvsgTHRe4pq0XwJqHKy
xCr0DbfMZ2TvLFXitS5ZgTbDHURljjHlE7Qdmk9AcFNpI0PCR9YrZ5Mgb10sMygr
kX3V3uzjx2YBjKEpX9fqk6Kf/aufUqQ1PRBHF3m6bSE=
=mtj/
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-20 11:34 ` Jeff Garzik
2015-12-20 11:43 ` s7r
2015-12-20 16:30 ` Chris Pacia
@ 2015-12-21 3:23 ` Tom Harding
2 siblings, 0 replies; 19+ messages in thread
From: Tom Harding @ 2015-12-21 3:23 UTC (permalink / raw)
To: bitcoin-dev
On 12/20/2015 3:34 AM, Jeff Garzik via bitcoin-dev wrote:
> Ideally we should start having wallets generate those proofs now, and
> then introduce the max-age as a second step as a planned hard fork a
> couple years down the line.
>
> However,
> 1) There is also the open question of "grandfathered" UTXOs - for
> those wallets generated in 2009, buried in a landfill and then dug out
> 10 years ago
>
> 2) This reverses the useful minimization attribute of HD wallets -
> "just backup the seed"
Also, a change (#6550) has been merged to bitcoin core that removes
merkle branches from the wallet, and if pruning gets turned on (possible
in 0.12 with #6057), it would become quite a bit more difficult to spend
older coins under a change like this.
As a solution I would favor not removing wallet merkle branches.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
2015-12-20 16:35 ` Peter Todd
@ 2015-12-21 3:34 ` Jeff Garzik
0 siblings, 0 replies; 19+ messages in thread
From: Jeff Garzik @ 2015-12-21 3:34 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd <pete@petertodd•org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia <ctpacia@gmail•com>
> wrote:
> >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
> >bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >> 2) This reverses the useful minimization attribute of HD wallets -
> >"just
> >backup the seed"
> >
> >It would be nice if the bip37 filter matching algorithm was extended to
> >serve up the proof.
> >
> >And if server-based wallets did the same it would preserve the "just
> >backup
> >the seed" functionality.
>
> Exactly! The information will be out there - "just backup the seed"
> requires someone to have the exact same data needed to generate the
> TXO-unspent proof that my proposal requires to spend an old txout.
>
> tl;dr: jgarzik is incorrect; theres no difference at all from the status
> quo.
>
The data stored in the legacy case makes it possible to sign and send a
transaction without any connection to a network. The data stored in the
upgraded case, absent grandfathering, requires significant network sync at
a minimum.
The user experience and security parameters are different.
Thus, issue/recommendation #1.
[-- Attachment #2: Type: text/html, Size: 1951 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-12-21 3:34 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-12 20:09 [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox