Would you be open to using the Gitian (https://gitian.org/) build method for the live CD?  It would allow users to validate the distribution by having it built and signed by multiple developers.  I can help with this.

Sounds good.

In other news - BlueMatt got cross compiling to work with mingw, so we could get gitian to do those too.

Gavin,

BlueMatt was able to replicate the build process and got an identical hash.  I've also created tools to collect signatures and verify distributions, gsign and gverify here:

https://github.com/devrandom/gitian-builder/tree/master/bin

An experimental git repository for collecting signatures produced by gsign:

https://github.com/devrandom/bitcoin-release/tree/master/sample-release/c1.devrandom@niftybox.net

It seems we are far enough along to start using this process for releases and maybe even nightlies.  What do you need from me to make this a reality?

An IV is always transmitted before the ciphertext (or stored, in this case) and is necessary for decryption.  The IV's purpose is to start the encryption from a random state, so that encrypting the same plaintext twice does not result in the same ciphertext.  This prevents comparing two records that have the same initial segment.

I wrote up a low-trust third-party escrow system in bitcoin, here:

http://bitcointalk.org/index.php?topic=4723.msg68804#msg68804

I think you are trying to create a reputation system.  Such a system would be nice, but is too much additional baggage for solving just this one problem.  If you already had a general p2p reputation system, applying it here would be appropriate.

It doesn't seem to hurt to encrypt everything?  I think symmetric encryption can do the entire block chain in about a second.

http://www.cryptopp.com/benchmarks.html

A flexible system could do the following, with the user making some usability choices:

* Have the user choose a passphrase, and derive one or two secret keys OR the user chooses two passphrases
* Optionally encrypt the wallet as a whole with one secret key
* Always encrypt the private keys with the second secret key
* If the whole wallet is encrypted, prompt for passphrase on startup
* Optionally forget the passphrase after startup, while keeping the wallet secret key
* If passphrase was forgotten, or there is no whole-wallet encryption, and the user wishes to spend, prompt for the passphrase again
* Again, optionally forget the passphrase after spending

I think new keys can still be created automatically.  Just create them in batch ahead of time during spend operations.

Different passphrases for different key sets are an interesting idea, but usability would start to suffer due to complexity.  Might be better to have separate wallets.


I don't think there's any difference between #2 and #3.  In either case, the attacker can listen for the user's passphrase.

Sounds like a good initial plan.  Let me think about the best way to approach this in the client, as it involves multiple coordinating parties.

These use cases don't use multi-in or multi-out.  They have multiple pubkeys on a single output.  This allows multiple parties to cooperate in a transaction.  There's no way to implement escrow and such without scripts.

I agree that there should be a careful security review, but I don't think it's that difficult.  The main thing is to do validation of length and bounds, and have multiple reviewers of the code.

I went over the code and I don't actually see that many disabled operations.  Unless I am missing something, currently all clients accept blocks with complex scripts.   They only reject mining them.  So a miner could insert complex scripts into the block chain.  The security of the system as it currently stands does depend on making sure the scripting system is secure.

One thing I do notice is that OP_MUL doesn't have a bounds check.  Clients can be crashed with a few OP_DUP + OP_MUL in an otherwise valid block.  This seems to currently be a security issue.  I can do a more thorough review in a few days.

I found scripting to be one of the more attractive features of bitcoin.  Standard transactions just check that the receiver signs using their pubkey.  But the scripting language can do much more interesting things.

However, the scripting language is currently mostly disabled.  Only two simple types of scripts are allowed in the standard client due to the implementation of ::IsStandard() and Solver() - script.cpp:967.  Any transactions with a different script form will not be relayed or mined.  A block with such a script will be accepted, so miners can choose to extend support.  But it would be ideal if some scripting is allowed for mining and relay in the standard client to allow for wider adoption.

Low trust escrow

The transaction script can be in the form of:


or even:


This allows the transaction to be finalized by a third party escrow and either the sender or receiver.  None of the parties have to be trusted with the coins.

Immediate transactions

The problem with using bitcoin in time sensitive settings is that it takes many minutes for transactions to be confirmed to achieve low probability of double spends.  It would be ideal for some applications (e.g. mobile payments) to have immediately verifiable transactions.  This can be achieved with a variant on the escrow script.  The funds are converted to "certified funds" ahead of time:


The funds can then be spent incrementally by having the sender and certifier collaborate to create a transaction.  The certifier is a trusted third party that guarantees no double spends using its reputation.  If it sees too much spends for the funds, it simply refuses to cooperate in the creation of the transaction.

So what would it take to re-enable more general scripting?

New version pushed just now.

The default is now to use 127.0.0.1 while bootstrapping (on the host) and 10.0.2.2 in the VM.  This will always hit the host.

Let me know if it works for you.

Strange.  Could you try:

* While make-base-vm is running, run and make sure that the mirror arguments refer to 10.0.2.2
* Make sure that you didn't specify -i or --skip-image
* I just realized that the --quiet flag to gbuild actually does --skip-image due to a bug .  If you had this flag on, it didn't pick up the new base vm image.

I've just pushed a new version that fixed the latter and makes 10.0.2.2 the default.

I'm on irc if you want to chat instead of messaging here.

Try doing:


I think I'll make that the default.

Looking into this.

I see a couple of issues:

* If you have a limited number of public keys, information about the merchant's transaction volume is still leaked when the merchant spends their revenue coins.  Normally you'd be able to guess the merchant's profit margin, so just divide the outgoing transactions by (1 - profit_margin) to calculate the original revenue and transaction volume.

* Verifying funds received still needs to be done, so a bitcoind connection still has to be established before shipping.  If bitcoind interaction is required, might as well generate a batch of keys every hour or every day.

So it seems to me that generating unique transactions keys in batch and ahead of time is still the way to go.

VM within VM is tricky and I haven't tried it.  Maybe I should add EC2 API support to the gitian tools.

Ah, yes, running VM within VM is a problem.  I hear that's possible in some configurations, but haven't looked into it.

I'm available if you run into any issues with building and to compare hashes.

Would be cool if the builds used the gitian process:

http://bitcointalk.org/index.php?topic=2926.20

This would allow people to verify that the builds are not compromised.

Gavin,

Did you get a chance to build using the gitian process?  Would be cool to compare hashes.

http://bitcointalk.org/index.php?topic=2926.20

https://github.com/bitcoin/bitcoin/blob/27b7f3b43a3868cd4d4f97e03c35074c2ef12349/contrib/gitian.yml

Since you guys would be the first real users of the VM build process, you can influence the standard.   Maybe it can look in multiple locations, such as SRC/bitcoin.gitian-desc, SRC/gitian/bitcoin-desc.yml.  Do you have a preference?

The build descriptor will need to change slightly.  The commit hash has to be removed if you are committing it into git.  Also, need a bit more added to it to support creation of the whole .tar.gz file.  The latter requires that the build process be run twice, once with a 32 bit VM and once with a 64 bit one.  I tried compiling for 32 on a 64 bit VM, but there's no 32 bit dev packaging for gtk et al.

In any case, I should be able to tie up the loose ends in the next couple of days.