On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia
> wrote:
> >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
> >bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> 2) Th
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"
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 se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia 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
>bac
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 ge
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
On Sun, Dec 13, 2015 at 02:07:36AM +, Gregory Maxwell via bitcoin-dev wrote:
> On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
> 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
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 h
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 no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe
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 o
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-d
On Sun, Dec 13, 2015 at 9:17 AM, Chris Priest 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
> 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
On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest 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
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
On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
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
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 ru
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' re
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 th
19 matches
Mail list logo