Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-09 Thread Timo Hanke
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


[Bitcoin-development] Version 0.8.0rc1 ready for testing

2013-02-09 Thread Gavin Andresen
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 vulnerability: 

Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-09 Thread Luke-Jr
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