* [Bitcoin-development] vtxPrev
@ 2011-10-05 12:31 Michael Grønager
2011-10-05 12:50 ` Gregory Maxwell
0 siblings, 1 reply; 3+ messages in thread
From: Michael Grønager @ 2011-10-05 12:31 UTC (permalink / raw)
To: Bitcoin Dev
Hi !
I am looking into enabling a split between thin clients holding the wallet and server(s) holding the blocks and txdb.
To that end I am considering to simplify the WalletTx a bit and I came across the vtxPrev in the code. As I see it vtxPrev is only used for keeping a list of supporting transactions to enable resubmit of these in case the transaction it self and all its supporting transactions are lost due to some blocks becoming invalid as they are part of a dead-end part of the chain. However...
The vtxPrev stores 3 transactions back, but as transactions need 7 block to maturity and respendability isn't it overkill - I mean it is highly unlikely that a transaction gets invalid after 7 confirmations and the vtxPrev are guarding against resubmission of transaction more than 21 confirmations back. Further, we cannot guarantee that the transaction owner is online at the time and the money could have been re-spent for others anyway.
So bottom line:
Do we need the vtxPrev at all ? Or did I miss out something ?
Cheers,
Michael
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] vtxPrev
2011-10-05 12:31 [Bitcoin-development] vtxPrev Michael Grønager
@ 2011-10-05 12:50 ` Gregory Maxwell
2011-10-05 13:44 ` Michael Grønager
0 siblings, 1 reply; 3+ messages in thread
From: Gregory Maxwell @ 2011-10-05 12:50 UTC (permalink / raw)
To: Michael Grønager; +Cc: Bitcoin Dev
On Wed, Oct 5, 2011 at 8:31 AM, Michael Grønager <gronager@ceptacle•com> wrote:
> The vtxPrev stores 3 transactions back, but as transactions need 7 block to maturity and respendability isn't it overkill - I mean it is highly unlikely that a transaction gets invalid after 7 confirmations and
They don't need 7 blocks to maturity and respendability. The software
will attempt to use older inputs when available but if not it will use
what it has. It's also prone to respending its own outputs quickly
because it reasonably trusts that it won't doublespend its own
transactions.
And, yes, if there is a deep split then its possible that inputs might
have been spent differently in the new split. But it's not especially
likely. Retransmitting one of your own txn's parents if its dropped
but not yet impossible sounds prudent to me.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] vtxPrev
2011-10-05 12:50 ` Gregory Maxwell
@ 2011-10-05 13:44 ` Michael Grønager
0 siblings, 0 replies; 3+ messages in thread
From: Michael Grønager @ 2011-10-05 13:44 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
Oups - I was reading the code wrongly - going through AddSupportingTransactions carefully again...
The vtxPrev contains a list of the supporting confirmations up to 3 confirmations back. So it is only of relevance (and only gets filled) if you accept coins that are less than 3 confirmations old. In this case you would like to resend the depending transactions to the network in case of chain splits.
This makes much more sense, but also, it is only of relevance when you accept newly earned coins. And it will only be of relevance for half an hour or so.
Cheers,
Michael
On 05/10/2011, at 14:50, Gregory Maxwell wrote:
> On Wed, Oct 5, 2011 at 8:31 AM, Michael Grønager <gronager@ceptacle•com> wrote:
>> The vtxPrev stores 3 transactions back, but as transactions need 7 block to maturity and respendability isn't it overkill - I mean it is highly unlikely that a transaction gets invalid after 7 confirmations and
>
> They don't need 7 blocks to maturity and respendability. The software
> will attempt to use older inputs when available but if not it will use
> what it has. It's also prone to respending its own outputs quickly
> because it reasonably trusts that it won't doublespend its own
> transactions.
>
> And, yes, if there is a deep split then its possible that inputs might
> have been spent differently in the new split. But it's not especially
> likely. Retransmitting one of your own txn's parents if its dropped
> but not yet impossible sounds prudent to me.
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager@ceptacle•com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-10-05 13:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-05 12:31 [Bitcoin-development] vtxPrev Michael Grønager
2011-10-05 12:50 ` Gregory Maxwell
2011-10-05 13:44 ` Michael Grønager
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox