Topic: Mining pool support for multisignature transactions (Read 2164 times)

OP_EVAL, and OP_EVAL-bitcoin-address support were pulled into the master git branch two days ago; the plan is still to evaluate miner support on January 15, and if a majority of miners are supporting it (looks like that won't be a problem), to roll out version 0.6 with the low-level support fully enabled.

And Luke-Jr is correct: sending coins into an OP_EVAL transaction is perfectly safe, but until February 1 it will be unsafe to spend them.

Actually, I think it probably is... just not safe to spend the outputs yet (or enable others to do so).

OP_EVAL support is added to my setup and I just tested it on mainnet.
Ready to enable it before the end of this month.

BTC Guild will be adding support for multisignature transactions in the next couple of weeks.

These bytes at the end of the coinbase:  074f505f4556414c
... are the 7-character string "OP_EVAL" (07 is the length, 4f is the letter O, etc).

There are no OP_EVAL transactions in that block; it isn't safe to send OP_EVAL transactions until after a majority of miners support it.

I believe Eligius is the only pool supporting OP_EVAL right now; Tycho of DeepBit has finished integrating the backport and has said he'll start supporting it after more testing, before the end of this month. Last I heard slush was also working on supporting it.

I dont' see the OP_EVAL nor OP_NOP1 in this block ?
And how many pools is supporting this "OP_EVAL"?

Eligius is the first pool to support OP_EVAL-- thanks Luke-Jr !  Block 155974 is the first "I support OP_EVAL" block in the chain.

The pull request for the next version of bitcoin is ready to go:
  https://github.com/bitcoin/bitcoin/pull/669

... and there are backports of just the changes relevant to mining available at these git branches:
  https://github.com/gavinandresen/bitcoin-git/tree/v0.3.23_op_eval
  https://github.com/gavinandresen/bitcoin-git/tree/v0.3.24_op_eval
  https://github.com/gavinandresen/bitcoin-git/tree/v0.4.1_op_eval

Not related to multisignature transactions, but I was working on an idea this weekend that needs an API exactly like this. Thanks.

I'm proposing one new RPC command:  'addmultisigaddress'  ... that combines several public keys into one BIP 13 -style newfangled bitcoin address.

You get the public keys from the 'validateaddress' RPC command, which I've extended to give the full public key if you give it one of your bitcoin addresses.

I extended the 'send*' RPC commands so they know how to send to the newfangled bitcoin addresses, and can send coins you received as multisignature transactions if you hold all the corresponding private keys (listtransactions will also show you them, getbalance counts them in your balance, etc).  So yes, anybody can generate new transactions to test...

Alan Reiner is proposing BIP 10 as the 'real' way to get multisignature transactions signed and spent:  https://gist.github.com/1321518
(no implementation yet, as far as I know).

BTC Guild will be ready to support the change as soon as shadders has had time to test the compatibility within PoolServerJ.

I just mean a hexstring version of a few transaction on a webpage where we can easily copy/paste them into test code.  Extracting tx's from bitcoind database is non-trivial for java numpties like me...


I just mean make a new tx after each new block appears or at least at some regular interval so we can test building blocks knowing that one of these new tx types is included.  Actually if there's an rpc call available to create one that would work as well... Then people testing can just create one when they need it.

Great!


Unless Mike messed up his implementation of the OP_NOP1 and made it do something other than be a no-op, there should be no problem  (OP_EVAL re-defines OP_NOP1 to do stuff instead of doing nothing, but all OP_EVAL transactions are valid if the OP_EVAL is interpreted as a no-op).


Publish how? I already made a couple of testnet transactions using OP_EVAL; I will make a few on main net (assuming Luke doesn't change Eligius to reject OP_NOP1 transactions). And I wrote thorough unit tests that create valid/invalid OP_EVAL transactions.

What do you mean by "everytime there's a block change" ?

"OP_EVAL" can be anywhere in the coinbase, I'll probably write a little tool using bitcointools to look at OP_EVAL adoption over time will make sure it doesn't care where the string appears.

The next release of poolserver, due in a few days, will be generating blocks internally but using a bitcoind as a trusted source of verified transactions.  So pool ops using PSJ will be able to make the choice by running a daemon that does or doesn't accept these transactions.


I think that's plenty of time and I'm happy to add OP_EVAL string to the coinbase script.  My only concern is whether bitcoinj will have a fit trying to parse these new transaction types.  If changes need to made to bitcoinj I'm happy to do it if Mike isn't already planning to.  What would make things easier though would be if someone could publish a set of test transactions both for testnet and production.  And also if there was some kind of automated script broadcasting some sample transactions on testnet everytime there's a block change.

Can you ensure that there's no rules that mandate 'OP_EVAL string as a vote' should be put in a particular part the coinbase input script.  MM headers have to appear in the 1st 20 bytes (why I don't know) and that space is getting a little cramped already so it would be much better if it could be put at the end of the script.

I think there's no reason that mining pool won't including this.

Evaluating this...

I'd be willing to patch my instances so long as enough notice was  given and the transition is handled much better than the Namecoin fiasco. 

Full protocol writeup and disclosure is a must. 
Patches against, at a minimum 4.0 and possibly going to back to 3.24.
JK Patch compatible would be nice (though I'm not running JK patches at the moment, but I am running some patches for NMC)
Luke's MM NMC solution mainlined in 5 or a derivative thereof so that we can initiate processes on submitwork() outside of bitcoind which would allow both NMC/MM AND in relation to this the ability to kick off something to handle the signatures/verification of this proposed change in an automated fashion if need be.

I probably have more, but I can't think of it off the top of my head. 

I like the overall idea of it, though, that's for sure. 

I just sent this email to several of the top mining pools; I'm also putting it here to get wider feedback from "the mining community":

---

I'm writing to the top mining pools to see if you will support Bitcoin Improvement Proposals 11, 12, and 13:
 https://en.bitcoin.it/wiki/BIP_0011
 https://en.bitcoin.it/wiki/BIP_0012
 https://en.bitcoin.it/wiki/BIP_0013

I think they are critical to making Bitcoin more secure for people who have never heard of GPG or AES. They don't solve the wallet security problem, but they put in place low-level mechanisms that will allow higher-level services that DO solve the "computer virus stole my bitcoins" problem. Once multi-signature transactions are supported by the network, Bitcoin wallets can be coded to contact "Wallet Protection Services" to get a second signature/authorization before coins can be spent (details of exactly how the Wallet Protection Service and the client communicate will be in future BIPs). They will also make it possible to create escrow services that cannot spend the bitcoins in escrow among other interesting use cases.

This same feature might be used to keep your pool's bitcoin balances more secure, also-- you could run your own Wallet Protection Code on a separate machine that (perhaps) required manual intervention before providing a second signature on pool payouts if some unusual payout activity was occurring because somebody managed to break your security and get access to the pool's wallet.

I'm proposing extreme caution rolling out support for multi-signature transactions, and, especially, supporting the OP_EVAL feature that allows more secure bitcoin addresses-- and that is why I'm asking you whether or not you're willing to patch your mining pool software sometime in the next two months to support the new 'standard'
transaction types.

I've already written an implementation for Bitcoin 0.5 that will soon become a PULL request.

The new features are backwards-compatible with existing miners and clients, but we do have to be careful when rolling out OP_EVAL because an attacker could create non-standard transactions and try to split the block-chain.

Here is the timeline I've proposed in BIP 0012 :

Now until Jan 15, 2012 : miners update their software, start including CHECKMULTISIG and OP_EVAL transactions in blocks they mine, and indicate support by including the string "OP_EVAL" in the blocks they produce.

Jan 15, 2012: we assess support for the new feature by looking at the percentage of blocks that contain "OP_EVAL". If a majority of miners are not supporting it, then deployment will be delayed or cancelled (a setting in bitcoin.conf controls the switchover date, with the default being Feb 1, 2012).

Feb 1, 2012: assuming there was majority support on Jan 15, OP_EVAL is fully supported/validated.

--------------
Questions I have for you:

Is there anything I can do to make it easier for you to support these new features?  For example, would patches against an earlier version of bitcoind be useful?  (if so, what version?)

Is the timeline reasonable?

Questions you might have:

What happens if you don't support these new transaction types but a majority of other miners do?

If you do not put non-standard transactions in your blocks, then nothing will happen.

If you DO put non-standard transactions in your blocks, then you would be vulnerable to an "invalidate blocks under the new rules" attack, where somebody sends you a transaction that is valid under the old interpretation of the OP_EVAL opcode (which is a no-op) but not valid under the new rules.  Your miner would put that transaction in blocks that you mine, and all of your blocks would be rejected by the majority of miners.

What happens if you DO support these new transaction types but a majority of other miners do not?

All transactions that you put into blocks will be valid under both the old rules and the new rules, so there is no danger that blocks you create will be rejected by the network. There IS a danger that the rest of the network will accept a block under the old rules that you consider invalid under the new rules; that is why I am proposing that we evaluate acceptance of the new rules on January 15.

Can you support one of the BIPs but not all of them?

Yes-- supporting CHECKMULTISIG as a standard transaction type (BIP 11) can safely be deployed right now, there is no danger of a block-chain-split, etc.

BIPs 12 and 13 will let users (or mining pools) use short bitcoin payment addresses to have bitcoins go directly into secure, multi-authentication-required-to-spend wallets.