Split from the press hits topic:

The only "skeleton key" I have is the private key for alert messages, that lets me sign messages that are broadcast and then displayed in the client (see https://en.bitcoin.it/wiki/Alerts for details, and the alerts that have been sent).

MAYBE he is saying that the core developers could slip in a change to the source code without anybody else noticing... but we've worked hard to make that impossible (with things like the gitian reproducible build system so people can verify that we are creating executables from the source code that anybody can look at).

Smells like plain-old FUD to me.

The Bitcoin ecosystem consists of more that just miners, and even if miners decided to try to form a cabal to increase inflation merchants, users, and exchanges could all veto their block-chain by simply refusing to recognize it.

I think the policy of which transactions to keep in the memory pool is fundamentally different, because miners can do whatever they like and there's not a whole lot merchants/users/exchanges or other miners can do about it. There's no way to enforce a "first broadcast version of a transaction must be mined" rule, if there was then we wouldn't need the block chain at all.

As for re-writing the blockchain if an after-the-fact, large-fee double-spend is broadcast:  I think that's covered by this case:
Or, in other words, you'd need to be pretty sure that you've got a majority of miners who will cooperate with you to rewrite the block chain. The longer the chain, the harder that will be (because it becomes increasingly likely that one of your co-conspirators mined one of the blocks you want to overwrite).

Some of the big mining pool operators are already going their own way, experimenting with new types of transactions (e.g. deepbit and eligius), so I suspect the answer to your question "Can 'we' please hold off..." is "No."

Discussions like this one are how I start to understand parts of the protocol like nLockTime and transaction replacement better.


As for BIP 16 draining effort away from making the standard client scale:  I've been saying for a year that my top priorities are network stability and wallet security. Making the standard client scale is, in my opinion, a lower priority; I don't want a super-scalable client with a 4-minute blockchain initial block sync time if it is vulnerable to the user clicking one wrong link and getting infected by a trojan wallet stealer.

As I told Matthew when I spoke with him a couple of weeks ago, I also think this is a fantastic idea and plan on helping the CLAG however I can. Legal and regulatory uncertainty is perhaps the biggest barrier for companies who might be thinking of launching projects involving Bitcoin, and having a reliable source of up-to-date accurate information about the issues will be incredibly valuable.

Hopefully in a couple of years the CLAG's biggest problem will be figuring out what it's role should be as similar groups, inspired by the CLAG, spring up all over the world to tackle the unique legal issues in each country.

In the long run, I think we have to assume that miners will do what is most profitable, and design escrow/payment protocols around that assumption.

Replacing non-final transactions in the memory pool potentially opens up a whole bucket of worms, but I think the short-term challenge is to figure out if we should change the rules we have now. If we do (I think we should), then I think it would be a mistake to do anything other than "create rules that will maximize miner profits."  Because if we do something else, then sooner or later I believe there will be a "miners special" version of the code that has miner-friendly rules.

---

If you agree with me that the default rules in the client should maximize miners' profits, then it seems to me there's one simple rule change we should make:

If you've got two otherwise equivalent transactions that spend the same input(s), keep the one with the most fees.

Right now, the rule is "keep the first one you see."

The bag of worms comes into play if you've got two transactions that spend the same input(s) that, for example, look like this:

Transaction 1:  final transaction (can go into a block RIGHT NOW) that has a fee of 0.005 BTC
Transaction 2:  transaction that won't be final for 3 days that has a fee of 0.1 BTC

Should a miner put Transaction 1 into the block they're mining and take the smaller fee now, or not include it, hoping that nobody else mines Transaction 1 in the next 3 days so maybe they can mine Transaction 2 and get the bigger fee?

I'm not an expert in game theory, but I believe the winning strategy in the above situation, assuming everybody knows about both transactions, is to mine Transaction 1 right away (any economists reading who know a lot more about game theory than I do?).

That suggests the rules for transactions that spend the same inputs aught to be:

1. If you have two free transactions, keep the first one you see.
2. If you have a free and a fee-paying transaction, always keep the fee-paying one.
3. If you have two final, fee-paying transactions, keep/mine/relay the one with the higher fee.
4. If one or both of the transactions is non-final, keep/relay the one that will become final first.

Thanks, that should be very helpful.  I opened issue #1065 https://github.com/bitcoin/bitcoin/issues/1065

Write up a proposal, start experimenting on testnet, recruit people to think really hard about how whether or not what you're proposing could be abused to compromise security or could make a denial-of-service attack easier...

I'm against changes that might make Bitcoin a tiny bit better, but if you've got a well-thought-out proposal for how to make Bitcoin much better in some way then I'll help you argue for it.

+1

Personally, I consider the coin creation function (50 BTC every 10 minutes, halving every 4 years) and rules for whether or not you can spend the coins you have (if, and only if, you can satisfy the scriptPubKey by creating an ECDSA signature then you can spend them) sacrosanct. Them's the rules of Bitcoin, change them and it ain't Bitcoin any more.

Extending Bitcoin to new and wonderful types of transactions is fine, and, actually, I believe Therilith could build most of what he wants on top of Bitcoin using pre-signed fee-only non-final transactions with a lockTime 10 years in the future.

Convincing people to agree to do that would be another thing all together...

Yes, if Bob puts in a deposit it adds a step internally.

I think for this to have a reasonable user-interface Alice and Bob's bitcoin clients will need to communicate in real time.

My inclination is to add JSON-RPC methods to bitcoin-qt/bitcoind to support this, and not build it into bitcoin-qt's GUI (or at least not right away). I'm imagining Armory or little "let's make a deal" 2-party-escrow-apps that... Do The Right Thing.

Random UI thoughts:

Alice could be asked "How much do you trust Bob?"  and "How much do you think Bob trusts you?"  If an answer is "not at all" then propose an escrow that requires a substantial deposit.  If the answer is "a lot" then maybe no deposit is required. It'd be way spiffy cool if it was automagically tied into the #bitcoin-otc web of trust sytem...

(... more random thoughts: would IRC as the communication mechanism under the covers be a good or bad idea?  might be a convenient way to prototype...)

I'm imagining Bob gets the details of the proposed escrow and can either agree or disagree (maybe with a message to let Alice know what he WOULD agree to).

Well, if DISPUTE is a fee-only transaction then miners have a VERY strong incentive to drop LAZY_ALICE and mine DISPUTE instead. I don't think we'd have trouble asking miners to support a code change that is something like:


etotheipi, I've been thinking about your comment "I don't like the asymmetry" ...
LAZY_ALICE and DISPUTE are, I think, symmetric-- Alice holds DISPUTE in case Bob doesn't hold up his end of the bargain, Bob holds LAZY_ALICE in case she doesn't.  I proposed that DISPUTE have an earlier lockTime than LAZY_ALICE, but maybe that's not necessary.

If Alice really doesn't trust Bob, then I think the whole scheme also works if Bob puts a "good faith security deposit" of bitcoins into the mix.

---

The complexity of all this (5 possible transactions, different states the escrow can be in, initial communication to initiate the escrow) makes me nervous. Even just figuring out how Alice and Bob's clients talk to each to setup the escrow isn't obvious.

Is anybody else seeing anything like what jetmine is seeing?  Anybody else running CentOS 5.6?  Did you compile from source or are you using the binaries we compiled?

My 0.6 nodes running on Ubuntu 11 have been rock solid.

The "CBlock::ReadFromDisk() : OpenBlockFile failed" is very odd, that should never happen.  You aren't running with a -datadir on a network drive or something are you?

RE: filling addr.dat:  that is one of the denial-of-service attacks fixed by the 0.6 release.

https://gist.github.com/830ca16758fb9ad496d7   : I created it as a 'private' gist because it is only half-baked.

RE: lockTime and the memory pool:

Note:  I'm using an "Alice pays Bob" scenario as described in the above gist:

If neither party is cheating, then the pre-signed DISPUTE  should NOT get broadcast until there really is a dispute. Instead, Alice and Bob's clients hold on to it.

So it is not in any miner's memory pools, and if there is no dispute nobody besides the two people involved in the transaction ever know about it.

Of course we have to assume that people WILL try to cheat, so the question becomes: what if Alice or Bob broadcasts DISPUTE prematurely?  Would anything bad happen?

I believe the answer is no, assuming Bob waits for transactions to be confirmed.  If DISPUTE is in "everybody's" memory pool, then any other transaction involving the escrowed funds will just be ignored. Even if Bob's client didn't see the DISPUTE broadcast (maybe he was offline) but later saw the SUCCESS transaction broadcast from Alice, SUCCESS would never be confirmed.

On the other hand, if not "everybody" has the DISPUTE transaction in their memory pool and Alice broadcasts SUCCESS, then it will likely be picked up by a miner and confirmed.  Once it is in a block, the conflicting DISPUTE transaction gets dropped from everybody's memory pool as a failed double-spend.  Given the churn in the nodes connected to the network, I expect this would actually be the most common case.

If Bob's client does see DISPUTE broadcast, it should probably let Bob know that Alice is unhappy and has disputed the transaction.

DISPUTE (which will be given a non-final sequence number) cannot get into a block until after lockTime.

---

All of the above is based on my best understanding of how the Satoshi code works right now; prototyping and experimenting on the testnet would be a good next step to make sure it actually behaves the way I think.

If I'm reading their specs correctly, if A manages to break the chip she could generate duplicate transactions for the full value stored on the chip to B and C and D (and E and F and...).

But she wouldn't be able to double-spend the same funds to B, because B's chip is able to detect that attempted double-spend.

Eventually, I assume the Mint would figure out that the same funds were spent at B and C and D and... etc, just like the Mint eventually figures out when a lot of counterfeit paper notes are being spent in a particular area. And I imagine they'd deal with it the same way, interviewing merchants to ask them if they have a record of who made a transaction at a particular time, etc.

And assuming B/C/D/... did nothing wrong I bet the Mint honors all of the the A -> B/C/D/... transactions, so B/C/D/... don't lose any money. The Mint eats the loss (it just shows up as inflation in the money supply, so really EVERYBODY pays for the fraud), and if the problem gets large enough they declare version 1.0 of their chips obsolete and come out with a New and More Secure version.

It all looks pretty nifty to me, I hope it is a big success; it could be a great way to buy Bitcoins (non-reversible, cash-like...).

All righty... you're the first person I've heard that from.

Please file bug reports on the github issue tracker. Include enough information so we can reproduce the problem (what platform? what seems to cause the problem? etc) and it might get fixed.

I say "might" because if you're serving up a big mining pool running bitcoind on Windows... well, none of the current core developers work on Windows.

I think it is really important that the bitcoins involved in failed escrows not be destroyed, but EVENTUALLY make their way back into the economy.

So I'd really like to see network and client support for having both people pre-sign and hold on to a transaction with a far-in-the-future lockTime (maybe as a fee-only transaction).

Nope, sorry, have higher priority things to do.

Upgrade to 0.6.

Multisignature adoption has to follow a multi-step process:

1. A majority of miners have to put multisignature transactions into blocks so they get confirmed.

2. A significant fraction of everybody else has to relay multisignature transactions so they reliably get to the miners (preferably more than 50%).

3. Depending on what you're using multisig FOR (escrow? secure wallets?), more technical infrastructure will need to be built.

4. After all of the above is done... y'all will be able to reliably use multisignature transactions.

April 1'st was the first step and we're doing pretty well with the second step, version 0.6 has a lot of support on the network already.  In fact, it is going so well I think we should turn on the 'addmultisigaddress' JSON-RPC method so people can start creating and experimenting with multisig with the 0.6.1 release.

Summarizing a discussion from #bitcoin-dev this morning:

The merge window for pull requests for a 0.6.1 release is now open.

This will be a bug-fix and code-cleanup only release, with the goal to have Release Candidate 1 binaries available for testing in three weeks: April 23'rd.  We want this to be a quick release cycle so we can start pulling new features for a 0.7 release in a month or so.

The major issues I would like to get resolved:
 # 1024 Correct passphrase crashed the client
 # 1012 bitcoin-qt slow to shut down after recent commits

There are currently 189 open issues in our bug tracker; lets try to get that down to under 100.

I know this will frustrate some of you who think development is happening at a snail's pace; feel free to pull and test new features (IPv6 support and coin control) that are important to you. Adequate testing is still our biggest issue, if you want your favorite feature to get into bitcoin core faster please spend some time helping test other people's favorite features.

About 20 minutes until the deadline... I expect to hear some very loud complaining about "I wasted a bunch of time generating orphan blocks why didn't you WARN me!" in the next few days. This is not an elaborate April Fool's joke.