[Bitcoin-development] vtxPrev
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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] vtxPrev
On Wed, Oct 5, 2011 at 8:31 AM, Michael Grønager 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. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] vtxPrev
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 > 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: grona...@ceptacle.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mac libboost_thread or thread-mt?
On Tue, 2011-10-04 at 16:40 -0700, Brian McQueen wrote: > I installed boost via the mac ports. Its got lobboost_thread-mt, but > it doesn't have libboost_thread.a. Should I modify the makefile or get > a different version of boost? > (from http://stackoverflow.com/questions/2293962/boost-libraries-in-multithreading-aware-mode) The -mt suffix means built in multithreading aware mode (what this means for a threading library I have no idea), however that suffix was removed from Linux and Mac builds in 1.42. If you are linking against 1.42+ on Linux/Mac, adding/removing the -mt suffix means nothing AFAICT. Matt -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Transaction Delivery and Storage
I imagine a lot of the things on the contracts page will be implemented by specialized software that interacts with the Bitcoin network directly. Transactions would then be moved around, for example, by having clients do HTTP POSTs of protocol buffers to servers that are listening and know how to interpret the received messages. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mac libboost_thread or thread-mt?
I updated src/makefile.osx and doc/build-osx.txt today, assuming that the MacPorts versions of dependencies will be used and the -mt boost libraries will be used. I also modified makefile.unix and makefile.osx to auto-build dependencies using gcc's -MMD option. -- -- Gavin Andresen -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mac libboost_thread or thread-mt?
Bad update. Macports has a couple of boost packages. Install the newer 1.46 ones. -- Douglas Huff On Oct 5, 2011 1:43 PM, "Gavin Andresen" wrote: > I updated src/makefile.osx and doc/build-osx.txt today, assuming that > the MacPorts versions of dependencies will be used and the -mt boost > libraries will be used. > > I also modified makefile.unix and makefile.osx to auto-build > dependencies using gcc's -MMD option. > > -- > -- > Gavin Andresen > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
