Pushing Partially Signed Transactions to other Bitcoin Clients

[No_2]

I'm trying to understand how transactions are signed sequentially for m-of-n. I'm trying to find out if there is a way to push (and/or pull) a partially signed transaction for m-of-n from one Bitcoin client to another. And if so is this done over a bind()ed TCP socket? Or can it also be done via something like an RCP API?

If so:

• What triggers the transaction being sent?
• Can you specify who the recipient is?
• Can you point me to the code which implements this?

[1714115340]

1714115340

[1714115340]

1714115340

[1714115340]

1714115340

[1714115340]

1714115340

[CIYAM]

I don't think this can be done using any "standard" client (things like "coin-join" are somewhat similar and they require specialised software).

The raw tx RPC calls will let you build up the tx piece by piece but a non-complete tx is not able to be broadcast to the network (AFAIA).

[No_2]

I don't think this can be done using any "standard" client (things like "coin-join" are somewhat similar and they require specialised software).

The raw tx RPC calls will let you build up the tx piece by piece but a non-complete tx is not able to be broadcast to the network (AFAIA).

Thanks.

How does a Bitcoin client start a multisig and notify another client to sign for it? Do you know where the source code for this is located?

[CIYAM]

How does a Bitcoin client start a multisig and notify another client to sign for it? Do you know where the source code for this is located?

It can't do that (as I explained above).

You can create the raw tx using the RPC API (or the new tool bitcoin-tx) but you'd have to send the incomplete raw tx using a different method (such as via email).

[No_2]

It can't do that (as I explained above).

You can create the raw tx using the RPC API (or the new tool bitcoin-tx) but you'd have to send the incomplete raw tx using a different method (such as via email).

Ah, misunderstood.

So you're saying one can create the partially signed TXs via the RPC API, but they have to be transferred via another medium/protocol?

If so can you point me at the RPC API code where this is done.

Thanks again, this is very useful.

[CIYAM]

If so can you point me at the RPC API code where this is done.

I don't think source code is going to help you - but I think the new tool "bitcoin-tx" might be what you want to look into (I am not sure if there is much documentation about its use yet).

[CIYAM]

I am a little surprised that others haven't replied to your question actually (I've been so busy on my own project that I haven't even had time to digest all the new stuff from the latest version of Bitcoin).

It is certainly relevant to ask whether or not it is planned for the Bitcoin network itself to ever handle such things as sending around partial txs.

[No_2]

I am a little surprised that others haven't replied to your question actually (I've been so busy on my own project that I haven't even had time to digest all the new stuff from the latest version of Bitcoin).

It is certainly relevant to ask whether or not it is planned for the Bitcoin network itself to ever handle such things as sending around partial txs.

To be clear we are looking at approaches to get an application to interface with Bitcoin (or any other Altcoin client) and get a transaction signed to set up an m-of-n escrow on that transaction. The transport medium/protocol can be our own so this is not an issue.

So is the RPC API call we're looking for signrawtransaction() for creating m-of-n and having various clients sign it in stages? It seems to preform the same function for either an multisig or a normal transaction?

Again thanks for the help.

[CIYAM]

So is the RPC API call we're looking for signrawtransaction() for creating m-of-n and having various clients sign it in stages? It seems to preform the same function for either an multisig or a normal transaction?

Yes - you can use that - and as I said you might find the new tool useful also.

[hhanh00]

Dealing with unsigned tx is a wallet job and therefore not part of the P2P protocol. There is no standard for their format and wallets serialize them with various degree of information attached. Just putting the raw bytes is usually not deemed secure enough because it gives no indication of the values of the inputs. It's a tough choice that offline wallets have to make.

[No_2]

Yes - you can use that - and as I said you might find the new tool useful also.

We're trying to be as backwards compatible as possible as we'll need to support many Alts. We are therefore trying to avoid new features. We will take a look at it though.

[CIYAM]

We're trying to be as backwards compatible as possible as we'll need to support many Alts. We are therefore trying to avoid new features. We will take a look at it though.

Might I hazard a guess that you are working on some sort of a "decentralised exchange"?

[No_2]

Yes, work is progressing very slowly though as we're doing it unfunded.

So far we've got the design to a level were it's stateless and doesn't need to modify any of the existing Alts.

However I'm not a programmer, all of our programmers are away at the moment, so I keep having to come here to get advice. For which I am very grateful.

[CIYAM]

You might be interested in this: http://ciyam.org/at/at_atomic.html (Automated Transactions or AT is a blockchain agnostic platform for doing "smart contracts" which could be implemented on a Bitcoin clone although so far no alt has attempted to integrate it).

Like you we have no funding (so I know your frustrations) - our ACCT is based upon TierNolan's work and will be working to allow trustless trading to occur between two blockchains (Burst and Qora) very soon (perhaps by the end of this month).

[No_2]

...
Like you we have no funding (so I know your frustrations) - our ACCT is based upon TierNolan's work and will be working to allow trustless trading to occur between two blockchains (Burst and Qora) very soon (perhaps by the end of this month).

Where can I read up on that?

[CIYAM]

Where can I read up on that?

http://ciyam.org/at

Unfortunately it is very high tech (not marketing friendly).

We managed this: http://www.bloomberg.com/research/markets/news/article.asp?docKey=600-201502200543M2______EUPR_____35f800000260e09a_3600-1

(which does actually mention Automated Transactions and CIYAM but was not a great press release IMO)

[No_2]

I see. Interesting. I'll take a look at this when my heads a little clearer.

We've assumed that we will be unable to change any source code, and that the system must involve no trust at all. Which so far we've managed to achieve. So users can swap any crypto for any crypto atomically between blockchains. They also get to specify how much double spend protection they want per trade on the decentralised exchange.

It also looks like (but we've not tested this part thoroughly yet) that the system can be extended to include fiat escrow via any bank account. So users can swap fiat for crypto with anyone anywhere.

[CIYAM]

It also looks like (but we've not tested this part thoroughly yet) that the system can be extended to include fiat escrow via any bank account. So users can swap fiat for crypto with anyone anywhere.

The fiat side is going to be your biggest headache as AML and KYC stuff are going to be a huge issue.

[No_2]

...
The fiat side is going to be your biggest headache as AML and KYC stuff are going to be a huge issue.

Its decentralised so we're not "in change" of that.

The simplified overview:

People sign up as fiat escrow on the network, they pay a deposit greater than the sums they are handling if they behave they get their money back at the end plus some fees for acting as escrow. Their is a reputation system and they can pretty much be anonymous if they wish except to the parties they deal with and have to exchange bank details. Escrow are rated based on amounts exchanged and how long they have had a good track record for.

Anyone else who downloads the wallet/exchange software to their machine can sign up, choose one of these escrow from a list and start an exchange either selling crypto and getting fiat or vice versa.

Another key constraint we've managed to follow is the design has to be very simple to use: all trades are direct from one currency to another and not via an intermediary such as coloured coins.

[CIYAM]

My guess is that trying to be "decentralised" when it comes to fiat will simply get you shut down.

(but I hope I am wrong for your sake)

The banks *hate* decentralised systems and will do almost anything to stop them (as they know it is the end of their control if they were to allow it).

Same goes for Mastercard/Visa networks for payments.

[No_2]

My guess is that trying to be "decentralised" when it comes to fiat will simply get you shut down.

(but I hope I am wrong for your sake)

The banks *hate* decentralised systems and will do almost anything to stop them (as they know it is the end of their control if they were to allow it).

Same goes for Mastercard/Visa networks for payments.

Our system is totaly decentralised, like Bitcoin. So like Bitcoin, it can't be shut down for being decentralised.

From the day of launch, if we disappear our decentralised exchange will carry on just fine without us. (Assuming we get to the finish line and it works).

[No_2]

Its a bit off topic but I'm going to ask you here anyway.

If an m-of-n transaction has been fully signed by various Bitcoin (or Alt) clients via their RPC APIs. How does one then broadcast that transaction onto the network? Can it be done via the client's RPC API too?

[CIYAM]

If an m-of-n transaction has been fully signed by various Bitcoin (or Alt) clients via their RPC APIs. How does one then broadcast that transaction onto the network? Can it be done via the client's RPC API too?

Once it has been fully signed you can just use the "sendtransaction" RPC to send it.

[No_2]

...
Once it has been fully signed you can just use the "sendtransaction" RPC to send it.

Is that sendrawtransaction()? As defined here:

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

[CIYAM]

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

Yup - that's the one.

[No_2]

...
Yup - that's the one.

Thanks a lot for all the help today. Got my MSDs done for now.