Re: [Bitcoin-development] Blockchain as root CA for payment protocol
On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote: First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses). This part has surely been done elsewhere as well and is orthogonal to the goal of this project. What is new here is the signatures _under_ the certificates. We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates. Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs). This seems to make signature lookup and verification reasonably fast: it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course). Why don't you use namecoin or another alt-chain for this? The UTXO set is the most expensive part of the blockchain because it must be stored in memory with fast access times. It's good that you have designed the system so that the addresses can be revoked, removing them from the UTXO set, but it still will encourage the exact same type of ugly squatting behavior we've already seen with first-bits, and again it'll have a significant cost to the network going forward for purposes that do not need to be done on the block chain. In https://github.com/bcpki/bitcoin/wiki/Technical you say that you have a minimum amount required for an outpoint to be valid, set at 0.05BTC. That's a nice touch, and sort of works because this is a consensus protocol, but if the exchange rate climbs significantly there will be a lot of pressure to reduce that value. (setting minimum value by chain height) What will happen then is there will be a mad rush to squat on previously unaffordable domains, further disrupting Bitcoin's purpose as a financial network. In addition you'll also have a second problem: squatting of subsequent transactions, particularly for valuable bcvalues. Basically if someone already has microsoft insert bcvalues after their tx in case they accidentally spend it. Of course, this will be done by people buying bcvalues as well. Again, all this further clogs up the UTXO set. I also can't figure out why you say signature lookup and verification takes 10s - this should be an O(1) operation if you maintain a mapping of candidate pubkeys to linked-lists of sorted applicable transactions. Finally, why is this implemented within the reference client? Use the raw transaction API and make up your own database. If you want, create a RPC command that allows you to query the UTXO set directly; this would be a useful feature to have. This patch will never be accepted to the reference client, so you'll just wind up having to maintain a fork. Even for a prototype this approach is ill-advised - prototypes have a bad way of turning into production code. In short, please don't do this. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.8.0rc1 status
Linux builds of 0.8.0rc1 are in good shape; easily gitian-reproduceable. Windows builds are varying with every compile, and I think I finally figured out why: we are not passing the -frandom-seed flag down into the leveldb build (I used objdump to dump two different binaries, and they differed only in the names of some leveldb objects). That should be an easy makefile fix. The OSX build is in pretty good shape, but needs https://github.com/bitcoin/bitcoin/pull/2286 to compile. So: I think the path forward is to announce 0.8.0rc1 with the binaries we've got, to get more testing. Then before final release (or rc2, if that is needed) pull #2286 and create and pull a patch to fix the windows non-determinism problem. I'm done for today, but should have time to sign the windows setup.exe and send out a rc1 announcement tomorrow. -- -- Gavin Andresen -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.0rc1 status
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote: Windows builds are varying with every compile, and I think I finally figured out why: we are not passing the -frandom-seed flag down into the leveldb build (I used objdump to dump two different binaries, and they differed only in the names of some leveldb objects). That should be an easy makefile fix. FWIW, this should be already mostly-fixed in pull #2243 I submitted 9 days ago... only thing not in that pull is changing gitian to use the standard CXXFLAGS rather than our non-standard DEBUGFLAGS (whether DEBUGFLAGS should be propagated to LevelDB or not is another conversation I guess). Luke -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.0rc1 status
Linux builds of 0.8.0rc1 are in good shape; easily gitian-reproduceable. Windows builds are varying with every compile, and I think I finally The OSX build is in pretty good shape, but needs So: I think the path forward is to announce 0.8.0rc1 with the binaries we've got, to get more testing. With this new minor bump, I'd like to encourage the project to perform a build check on FreeBSD 8.3 (gcc), and 9.1 (should be clang/llvm). I'll try to get to 8.x but may not be able to in time. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.0rc1 status
On 9 Feb 2013 00:50, Gavin Andresen gavinandre...@gmail.com wrote: Then before final release (or rc2, if that is needed) pull #2286 and create and pull a patch to fix the windows non-determinism problem. #2243 should fix that, I think. -- Pieter -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
