Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: helloworld on October 19, 2011, 10:56:29 PM



Title: Could GREEN addresses help with pruning?
Post by: helloworld on October 19, 2011, 10:56:29 PM
I've been reading more and more of the technical side lately and I am wondering if trusted "green" addresses could somehow help with blockchain pruning.

Example: Let's say A generates some bitcoins and then it gets spent through the following people/addresses:

A -> B -> C -> D -> E -> F -> G -> H -> I -> J -> K -> L

Normally the client software for the "L" address would have to store all the transactions all the way back to A in order to validate it's balance.

But what if that client software trusted the green address K enough such that it didn't need to download and store all the transactional data prior to it going through K? That would mean the data needed for that particular client instance could be lower.

I know that even if K is trusted, that doesn't necessarily mean the A through K transactions are really valid, it just means K believes they are.

Comments? Flaws? (Probably many - I just thought of this and haven't worked out any details)



Title: Re: Could GREEN addresses help with pruning?
Post by: MagicalTux on October 19, 2011, 11:36:31 PM
Pruning do not need green addresses. It needs blocks to be kept empty of any funds (ie. all funds to be constantly spent and respent). If it happens, it makes it possible to remove old blocks from the blockchain.


Title: Re: Could GREEN addresses help with pruning?
Post by: DeathAndTaxes on October 19, 2011, 11:43:49 PM
What if I don't trust the green address provider?

Green address should be an optional service and if you use it is between you and the provider.

If you trust Mt. Gox to cover any losses that emerge from a double spend then trust them.  If you don't then don't.

However the bitcoin network should consider that transaction untrusted until it has 6 confirms and can trace it back to origination.


Title: Re: Could GREEN addresses help with pruning?
Post by: MoonShadow on October 19, 2011, 11:53:47 PM
I've been reading more and more of the technical side lately and I am wondering if trusted "green" addresses could somehow help with blockchain pruning.

Example: Let's say A generates some bitcoins and then it gets spent through the following people/addresses:

A -> B -> C -> D -> E -> F -> G -> H -> I -> J -> K -> L

Normally the client software for the "L" address would have to store all the transactions all the way back to A in order to validate it's balance.

But what if that client software trusted the green address K enough such that it didn't need to download and store all the transactional data prior to it going through K? That would mean the data needed for that particular client instance could be lower.

I know that even if K is trusted, that doesn't necessarily mean the A through K transactions are really valid, it just means K believes they are.

Comments? Flaws? (Probably many - I just thought of this and haven't worked out any details)


Flawed, but that's irrelevent.  The pruning of the blockchain would not need to keep anything earlier than H anyway, and would immediately prune H once M was verified.  That's assuming that those transactions were older than the minimum block depth/age required by the pruning algo that the user has chosen.  Honestly, if J was deeper than 4000 blocks, there's no reason to even keep I once L has been verified and is 6 blocks deep.


Title: Re: Could GREEN addresses help with pruning?
Post by: helloworld on October 19, 2011, 11:57:50 PM
What if I don't trust the green address provider?

Then don't run this particular client software.


Green address should be an optional service and if you use it is between you and the provider.

Exactly:
Option 1) use regular bitcoin software which uses the full blockchain
Option 2) use modified bitcoin software which uses a published list of green addresses and cuts down blockchain

Anyway, the other replies have shown me that it's not needed / not going to work anyway.

Just a thought.