This thread is discussing two unrelated things.
Your first email asked about transaction pruning ("stubbing"). You're
correct. This doesn't do anything for initial chain download bandwidth or
time. In fact it makes it slower because you have the overhead of deleting
the old transactions. It exists
On 2012-01-02 14:41:10 -0800, Gregory Maxwell said:
> make this possible: https://bitcointalk.org/index.php?topic=21995.0
Neat! I had a similar idea but you've clearly beat me to [a big part of] it.
> Er, no— if a node controls the private keys for a transaction, and
> that transaction makes i
On Mon, Jan 2, 2012 at 5:23 PM, Elden Tyrell wrote:
> On 2012-01-02 05:31:19 -0800, Christian Decker said:
>> Later full blocks would be required to detect usable inputs for future
>> outgoing transactions.
>
> Er, yes, this is what I meant; I guess I should have been more specific.
>
> So, a para
On 2012-01-02 05:31:19 -0800, Christian Decker said:
> Later full blocks would be required to detect usable inputs for future
> outgoing transactions.
Er, yes, this is what I meant; I guess I should have been more specific.
So, a paranoid client cannot confirm reciept of coins until it has an
u
It can speed up the initial chain download. A newly created wallet will
have only new key-pairs, hence no incoming transactions (unless we have a
key collision, which is unlikely). So there is no need for a bootstrapping
node to download the chain with transactions. The chain itself can be
verified
5 matches
Mail list logo