No way this will be part of bitcoind. But it can be stand alone program with open source code.
Come on people, we have bounty for this.
Topic: (Bounty) SPEND the funds sent in that 2-of-3 transaction (Read 1491 times)
It's probably a good idea to get a product out there with this capability just to show it can be done.
Come on... do it
That's what I was thinking. Even better, if we had a
Code:
bitcoind signfile filename.trans
rpc command, the online wallet wouldn't have to hold the keys. The wallet could just allows each user needing to sign to download the transaction in plaintext, run the command, and upload the result. I don't know if they need to nest their signatures in a specific order or each sign the raw transaction, but the order could be enforced by the server if necessary. 
It's probably a good idea to get a product out there with this capability just to show it can be done.
Come on... do it
It's probably a good idea to get a product out there with this capability just to show it can be done.
Come on... do it
For now, use a different private key for each multisig transaction, import the key when your ready to spend.
Genius!!!
For now, use a different private key for each multisig transaction, import the key when your ready to spend.
Genius!!!
For now, use a different private key for each multisig transaction, import the key when your ready to spend.
Let's say we have multi signature transaction.
How can sign through RPC transaction that moves money from multi signature one into some address?
How can sign through RPC transaction that moves money from multi signature one into some address?
Spending funds from a 2-of-3 transactions works just fine, assuming all keys are available in a single wallet.
The problem is that obviously you do not want to require having all keys in one place - that would defeat the purpose. In what follows, a signature negotiation protocol (a la BIP10) will probably be suggested/implemented. The problem is not really the signing, it is rather communicating and coordinating among different wallets that requires an infrastructure that doesn't exist yet.
The problem is that obviously you do not want to require having all keys in one place - that would defeat the purpose. In what follows, a signature negotiation protocol (a la BIP10) will probably be suggested/implemented. The problem is not really the signing, it is rather communicating and coordinating among different wallets that requires an infrastructure that doesn't exist yet.
If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet
It kind of sucks... I thought it is already done... Can somebody slap RPC call for this??
$100 USD Bounty for this.
Jump to: