Re: [Bitcoin-development] Blockchain as root CA for payment protocol
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote: > > Why don't you use namecoin or another alt-chain for this? > > Because namcoin tries to solve a different problem, DNS, whereas I want > to establish an identity for a payment protocol. What is the technical difference here? Namecoin ties names to data; DNS is a specific namespace in it. There is no reason I know of that this identity stuff cannot be a new namespace. > You can argue that alt-chains _can_ be as strong as bitcoin, but they > don't _have to_ be. There is no guarantee how many people will > cross-mine. This is true of namecoin, but it does not have to be true of new merged-mined data. You could very well require the Bitcoin proof-of-work to be valid and the master header to be in the Bitcoin blockchain. > The alt-chain could even disappear at some point. If at some point your alt- > chain is no longer being worked on, then how do you prove that some old > bitcoin transaction went to an address for which there was a valid > id/certificate at the time of sending? If the certificate is based inside > bitcoin's blockchain then you will have a proof for the correct destinations > of all your old transactions as long as bitcoin exists. Yes, if people stop using your system, it won't work. Consider that a "this idea failed" scenario, where it doesn't matter. 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
[Bitcoin-development] Version 0.8.0rc1 ready for testing
Bitcoin version 0.8.0 release candidate 1 is now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.0/test This is a major release designed to improve performance and handle the increasing volume of transactions on the network. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Release-candidate 1 notes: The OSX binary reports its version as "0.8.0rc1-1-gba1d080-beta" due to issue https://github.com/bitcoin/bitcoin/issues/2285 . This will be fixed before the final 0.8.0 release. The Windows binaries could not be reproducibly built, due to issue https://github.com/bitcoin/bitcoin/issues/2288 . This will also be fixed before the final 0.8.0 release. How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoin-qt (on Linux). The first time you run after the upgrade a re-indexing process will be started that will take anywhere from 30 minutes to several hours, depending on the speed of your machine. If you have enough memory, running with the -dbcache setting (e.g. -dbcache=1000 ) may make re-indexing faster. Special notes for release candidate 1: -- If you helped test pre-release versions, there are two changes that you should be aware of: 1. Subdirectories in the data directory changed names; to avoid re-indexing the blockchain, rename: mv $DATADIR/blktree $DATADIR/blocks/index mv $DATADIR/coins $DATADIR/chainstate 2. The "undo file" format changed; if you see errors at startup during block validation re-run with the -reindex flag to fix them. Incompatible Changes This release no longer maintains a full index of historical transaction ids by default, so looking up an arbitrary transaction using the getrawtransaction RPC call will not work. If you need that functionality, you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more details). Improvements Mac and Windows binaries are signed with certificates owned by the Bitcoin Foundation, to be compatible with the new security features in OSX 10.8 and Windows 8. LevelDB, a fast, open-source, non-relational database from Google, is now used to store transaction and block indices. LevelDB works much better on machines with slow I/O and is faster in general. Berkeley DB is now only used for the wallet.dat file (public and private wallet keys and transactions relevant to you). Pieter Wuille implemented many optimizations to the way transactions are verified, so a running, synchronized node uses much less memory and does much less I/O. He also implemented parallel signature checking, so if you have a multi-CPU machine all CPUs will be used to verify transactions. New Features "Bloom filter" support in the network protocol for sending only relevant transactions to lightweight clients. contrib/verifysfbinaries is a shell-script to verify that the binary downloads at sourceforge have not been tampered with. If you are able, you can help make everybody's downloads more secure by running this occasionally to check PGP signatures against download file checksums. contrib/spendfrom is a python-language command-line utility that demonstrates how to use the "raw transactions" JSON-RPC api to send coins received from particular addresses (also known as "coin control"). New/changed settings (command-line or bitcoin.conf file) dbcache : now controls LevelDB memory usage. Running with (for example) -dbcache=1000 will use a gigabyte of memory and might make the initial blockchain download faster. par : controls how many threads to use to validate transactions. Defaults to the number of CPUs on your machine, use -par=1 to limit to a single CPU. txindex : maintains an extra index of old, spent transaction ids so they will be found by the getrawtransaction JSON-RPC method. reindex : rebuild block and transaction indices from the downloaded block data. New JSON-RPC API Features - lockunspent / listlockunspent allow locking transaction outputs for a period of time so they will not be spent by other processes that might be accessing the same wallet. addnode / getaddednodeinfo methods, to connect to specific peers without restarting. importprivkey now takes an optional boolean parameter (default true) to control whether or not to rescan the blockchain for transactions after importing a new private key. Important Bug Fixes --- Privacy leak: the position of the "change" output in most transactions was not being properly randomized, making network analysis of the transaction graph to identify users' wallets easier. Zero-confirmation transaction vulner
Re: [Bitcoin-development] Blockchain as root CA for payment protocol
On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote: > 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? Because namcoin tries to solve a different problem, DNS, whereas I want to establish an identity for a payment protocol. Your incoming payments will land on addresses that are derived (regardless which way) from this idenity. This makes your identity as important (securitywise) as anything else involved in the bitcoin protocol. Therefore I would not want to have payment-ids rely on anything _less_ than bitcoin's own blockchain. In particular not on PKI with centralized root CAs. But also not on namecoin or any other (weaker) alt-chains. You can argue that alt-chains _can_ be as strong as bitcoin, but they don't _have to_ be. There is no guarantee how many people will cross-mine. The alt-chain could even disappear at some point. If at some point your alt-chain is no longer being worked on, then how do you prove that some old bitcoin transaction went to an address for which there was a valid id/certificate at the time of sending? If the certificate is based inside bitcoin's blockchain then you will have a proof for the correct destinations of all your old transactions as long as bitcoin exists. Besides all this, as you mentioned namecoin specifically, that is overkill if you just want to link two hashes together. A single 2-of-2 multisig output would suffice for that. > 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. You are probably right that storing this in the _spent outputs_ would be better. There doesn't seem to be any type of client out there that would benefit from having to search UTXO only. Timo -- 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
I have done test builds on FreeBSD. Clean builds using gcc and clang, building both the qt gui and the command line daemon, and the tests run clean as well. The qt gui runs, and cleanly reindexed and caught up. I have no problems to report. I am not doing any adjustments apart from applying the needed changes to the include directory statements. On 9 February 2013 16:10, Pieter Wuille wrote: > > On 9 Feb 2013 00:50, "Gavin Andresen" 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 > > -- 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
