Whoever just cleared the last of my old sells at $6.50 has my gratitude.  Of course, if it hits $7 before it hits $6 from here, I'll wish I hadn't said anything publicly.

This is where I stopped reading.  You don't see your own life as a counter-argument?  We've chased short term profits that "destroy the environment needed to survive" so much that the world currently supports several billion people.

As for the rest of your posts, I'll give you 10 BTC if you can create 100,000 transactions sending .00000001 BTC each and get them into the chain before the end of the year.  They can be legitimate transactions back to yourself, or to whatever arbitrary hashes you want.

Yeah, I just grepped out p2sh and saw 8 NOP2SH and 4 p2sh.  If the 4 strings I found are actually for BIP17 instead of BIP16, it doesn't change my conclusion in the least.

Just by grepping the blk0001.dat file, I see 4 votes for, and 8 votes against.  I'm pretty sure that means that Luke is still against it, one person is for it, and the entire rest of the mining world is uncommitted.

If you really want to keep them divided, you'd be better off running two nodes, or using a client that can handle multiple wallet files.

Picking the transactions to redeem by hand or by script is a poor idea.  You are almost certainly losing both anonymity and security, which seems like a poor trade if you are looking for privacy.

There are no addresses.

Your wallet is a list of private/public key pairs.  When you want someone to pay you, you take a hash of a public key, then give them the hash.  To redeem that transaction later, you need to provide the same public key that created the hash, and prove that you know the private key that corresponds to that public key by signing the transaction with it.

The minimum amount of information needed to create a secure transaction to a single keypair is a single hash.  We then embed that hash into a string using special rules, and we call it an address, but it never exists in the bitcoin system as anything but a hash.

Now, say you want to create a transaction that can be redeemed by either of two different keypairs.  How much information do you need to create that transaction?  You need two hashes, one for each key, and then you can create a script that can be satisfied by either of them.

It gets worse.  If you want to have a (A and B) or C system, you need to provide hashes of all three keys.  If you want a (N of M) system, you need to provide all N hashes.

And that isn't all.  Not only do we need to provide 3 key hashes for (A and B) or C, but we need to standardize the interchange format so that you can create an address that includes the three hashes and the relationship between them.  And we need a format for (2 of 3), and another one for (3 of 4), and in general we need a format for every system.  The CEO and CFO can spend if they agree, but otherwise either of them requires a majority of keys from the board of directors?  New format.  Any junior officer can spend with the consent of either the CEO or the CFO and the consent of at least one board member?  New format.

With P2SH, the addresses that you give out are the size of a single hash, regardless of what lurks beneath.

The redemption transaction grows, since it will include the script in addition to all of the needed public keys, and all of the needed signatures.  But, that is a problem for the person spending from the complex transaction, not the person spending to it.

Heh.  You do know that both of those tools use websockets to pull data directly from the feed to your browser, right?

It isn't the server at mtgoxlive.com that gets out of sync, it is your browser.

The issue isn't "slightly" larger transactions.  Complex transactions can be much larger than normal transactions, and it puts the burden on the wrong party.  See this post.

They do make ZIF sockets for BGAs, but they are obscenely expensive except for very popular shapes.  When Intel ships a couple million 1156 sockets, those are only like $20 each, but the world market for CSG484 is probably only a few thousand units, so those sockets can be hundreds of dollars each.

You do understand that China is "buying" somewhere near 100% of the output of their domestic gold mines, right?

The reason China has so many gold mines is because they have very nearly zero gold reserves, and they don't want to buy a few thousand tons on the open markets.  Nothing is getting flooded any time soon.

Mind if I ask why you think you want to do this?

I will tell you exactly what happened today.  Ready?


I gave a much longer answer to (more or less) this same question several months ago.  Feel free to dig it out of my post history.  And, just to repeat myself:

If you've made money lately, then you are the yellow fish.  If you haven't, you are the red fish.  Either way, the blue fish is "not you".

It must be hell to be alive today with no clue about how anything at all really works.

Actually, gox just uses a queue with timestamps.  Their order matcher can fall behind during busy times.

When the queue is busy, everyone sees huge price swings and they try to place orders, but their orders are going to the queue, not the market.  The swings you are seeing right now on mtgoxlive.com are at least several minutes old already, possibly much older, and everyone frantically clicking their trade buttons and the bots scrambling to make sense of things are just making it worse.

Either ignore it and leave the flag set, or reject the transaction as invalid.  Ignoring it should be safe enough, but setting a limit (like 1) will prevent people from spamming up the chain with tons of pointless repeated NOPs.


Bounce the transaction, at least for now.  Maybe some day in the future we will be able to safely handle a full blown OP_EVAL, but we don't have to treat it like one right now.


You could either allow it to be set conditionally when encountered inside the script, or ignore placement and set the flag either way based on finding the opcode during static analysis.  Conditionally setting the flag might actually be useful.  I need to study up on the conditionals, but it could end up being a pretty short path to (N of M) or K, with transactions that could be triggered by either the P2SH script, or by the ordinary key.

We could even require that it be the first opcode for now, with the desire that the restriction be relaxed in the future, if safe to do so.


Well, not really.  There wouldn't be any magic scriptPubKey.  Any valid scriptPubKey could become magic by including the NOP.  In practice, this means that most P2SH scripts would be identical to NOP + the current magic script, but down the road when scripting is better developed, people would be able to trigger P2SH from an arbitrary script, maybe.

It could possibly turn out that there are no useful cases for combining ordinary scripts with P2SH, in which case it would turn out that all we've done is made the magic codes one byte longer.  Even then, having an explicit marker for "hey, I'm a special transaction" could turn out to be worth the ~5% bloat.

What you describe is an ugly hack, in my opinion.  But you are right that it is an entirely doable ugly hack.

First, that scheme requires that the recipient have an active node running at all times, or at least often enough to sweep receipts occasionally.  Second, it requires more transactions, up to twice as many, but less if the system gathers multiple transactions before sweeping.  Third, it requires that the extra transactions embed the all of the key hashes, making them rather large, and combined with the second point, it means a lot of needless bloat.  Also, it means a lot of hard to predict fees, since all of the extra transactions will be working from new, fresh transaction outputs.

In P2SH, there are no extra transactions, all transactions can be small regardless of the complexity of the redemption scheme, fees will be low since the ordinary oldest coins first policy can be kept, and it can all be done offline.

Also, I just realized that the sweeping scheme can reduce privacy and anonymity, since a sender will be able to watch for their payment to get swept and try to deduce extra information from the protection scheme.  In P2SH, all details of the protection stay hidden until the coins are redeemed.

For those that have never heard of it before, M*disc is a recordable media (currently DVD only) that uses a ceramic layer rather than an organic dye and metal foil.  Ordinary recordable media has a very short lifetime because the dye denatures and the metal foil oxidizes.  M*disc drives use a higher powered layer to burn holes into the ceramic layer, so they should be good for a long time.  Estimates are currently up into the 1000 year range.  I figure mine should be good for 50 years or so.

Hey Gavin, what do you think about making the new P2SH transaction recognition explicit rather than implicit?


I think that this would address Luke's (somewhat valid) complaint about the magic transaction special case code path, while still being exactly P2SH.

Very pretty.  Just make sure that you stop it after a second or two.  If the polycarbonate burns, you'll need a new microwave, and possibly a new kitchen.

Use M*Disc for long term storage of bitcoin wallets.  Of course, I haven't tested one in a microwave yet.