[bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[jl2012--- via 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"

[gb via 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.

Post by jl2012--- via 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
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Vincent Truong via bitcoin-dev]

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" <

Post by gb via 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.

Post by jl2012--- via 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
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gregory Maxwell via bitcoin-dev]

On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev

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.

[Chris Priest via 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

Post by Gregory Maxwell via bitcoin-dev
On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gregory Maxwell via bitcoin-dev]

Post by Chris Priest via bitcoin-dev
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.

[Chris Priest via 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.

Post by Chris Priest via bitcoin-dev
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.

[Gregory Maxwell via bitcoin-dev]

Post by Chris Priest via bitcoin-dev

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.

Post by Chris Priest via bitcoin-dev
precisely because paper wallets don't include UTXO data. This is like
adding the ability to partially seed a movie with bittorrent.

[...]

Post by Chris Priest via bitcoin-dev
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.

Post by Chris Priest via bitcoin-dev
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.

[jl2012--- via bitcoin-dev]

Post by Danny Thorpe via bitcoin-dev
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.

Post by Danny Thorpe 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."

[Tier Nolan via bitcoin-dev]

On Sun, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev <

Post by jl2012--- via bitcoin-dev
Back to the topic, I would like to further elaborate my proposal.
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.

Post by jl2012--- via bitcoin-dev
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.

[Ricardo Filipe via bitcoin-dev]

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 <

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Danny Thorpe via bitcoin-dev
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.

Post by Danny Thorpe 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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Gregory Maxwell via bitcoin-dev
On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev

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.

Post by Gregory Maxwell via bitcoin-dev
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.

[Jeff Garzik via bitcoin-dev]

On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev <

Post by Peter Todd via bitcoin-dev
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"

[s7r via 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?

Post by Jeff Garzik via bitcoin-dev
On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev
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"

[Peter Todd via bitcoin-dev]

On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <

Post by Jeff Garzik via bitcoin-dev
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.

[Jeff Garzik via bitcoin-dev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <

Post by Jeff Garzik via bitcoin-dev
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.

[Tom Harding via bitcoin-dev]

Post by Jeff Garzik via bitcoin-dev
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.

[Danny Thorpe via bitcoin-dev]

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" <

Post by jl2012--- via 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
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev