Bitcoin Forum

Two questions:

(1)  Does Bitcoin allow transactions to go directly from one client to another circumventing the network?  (Did they recently disable this?)

(2)  Can a user capture a transaction and sent the transaction via a different means (i.e. email or http) and have the transaction activated (or submitted) on the bitcoin network at a later time?

I don't understand this question.  How are you suggesting that it get from one client to another without traveling over a network?


While technically this is possible, I don't believe any current clients provide an easy user interface to do so.

If the point is to delay the payment such as sending cash through the postal service, then a multisig transaction would serve that purpose.

Can you explain why a multisig be necessary?

Could not the receiving application just broadcast the transaction at a later time into the bitcoin network?

Need to clarify question (1), I meant the (bitcoin) network ... not (any) network.  In other words, direct transfer without going through the bitcoin network.

If it doesn't go through the Bitcoin network then is isn't a Bitcoin transaction (full stop and this had always been the case).

You can send someone a private key of course but there is no guarantee that any BTC it had attached to it still will be when the receiver tries to spend it.

I'm still not sure what you are trying to say.  Direct transfer from one bitcoin client to another bitcoin client over a network such as a LAN or the internet is the definition of what "the bitcoin network" is, isn't it?

I suppose you might be asking if it is possible to get a transaction from one specific "sending" client to another intended "receiving" client without relaying it through additional clients?  This is certainly possible.  You just need to have your two clients connect directly to each other and block any/all other connections.

Of course, if you do so, the transaction won't get any confirmations.  It can't get confirmations without being seen by miners (or mining pools) and eventually being in a block that is relayed throughout the entire network.

I disagree.

I don't see any reason why you can't use createrawtransaction and signrawtransaction to generate a raw transaction.  This raw transaction could then be printed out and mailed via U.S. Postal Service to a receiver.  The receiver can then run sendrawtransaction in their own disconnected wallet.  Voila, transaction sent without the bitcoin network.

 Of course, it is a zero-confirmation transaction, and as such is carries a significant risk of double-spend until it is transmitted to the bitcoin network.  That's the important service that the bitcoin network provides and the ingenious solution that Satoshi came up with for preventing double-spends without a need for a centralized authority. You can receive a bitcoin transaction that has never ben seen on the bitcoin network, but if you want that transaction to be secured against a double-spend, you need to submit it to the decentralized consensus building process (also known as "mining").

As I stated - you have zero guarantee that it won't be double spent - so it is pretty much *useless* to do so unless you trust the other party 100% (in which case sending a private key is simpler than mucking around trying to create a raw tx).

In any case the OP has not made it clear what they are actually trying to do.

Sure, but that's true of ANY 0 confirmation transaction even if it is sent over the bitcoin network.

With Armory you can crate a transaction but not broadcast it to the network.

You can then for example save the signed transaction on a usb stick and transport it to any other pc with a Amory client, which then can broadcast it to the network.

There are at least 2 usefull functions for this:

1. Have your BTC in a offline pc that never touches the internet. Transaction are transported "manually" out of the wallet.

2. Keep your BTC in "cold transactions". Instead of having them in Paper Wallets, you can store transactions to the paper wallets and delete the orginal Wallet they came from. With this a thief would have to obtain the paper wallet and the transaction to get the btc.

There used to be a pay-to-IP mode, where your node would connect to the IP address, fetch a pubkey, and write a transaction to that key.  That mode was removed because it was totally unsafe (no authentication).

At any rate, the raw transaction API makes it (relatively) easy to create transactions and pass them around using whatever means you prefer.  As an example, I have created transactions on offline computers, printed them as barcodes, and scanned them in for broadcast to the network.

This is pretty useless in the simple case of A paying B.  As others have pointed out, the transaction that hasn't been seen by the network is easily double-spendable.  But it can be useful in more complicated applications.

I wouldn't say it's useless.  You could always create a transaction to someone (as Akka pointed out, it can be done with Armory), and then email it to them instead of broadcasting it.  Then it would be the same as writing a check from your bank checking account -- checks aren't guaranteed to have funds available to them, but if it's lost in the mail or the person moved (i.e. lost their wallet, etc), the coins never left your wallet.  

I had even thought about doing something like this in Armory as another kind of payment option.  

(1) Recipient gives the user his payment address.
(2) Sender, perhaps at a far later time doesn't know if that address is still valid, etc
(3) Sender creates a signed transaction and emails it to the recipient
(4) Recipient opens it in Armory and it says "This transaction sends 13.24 BTC to Wallet ABC" or "This transaction does not send coins to any wallet you own"
(5) Recipient presses "Broadcast" if they are happy with it.  Or replies with "this isn't valid, please use this address instead: ..."

It also makes MitM address swapping attack much less potent, because the person broadcasting is much more capable than the sender, of recognizing whether the transaction goes to their own wallet (edit: okay so this isn't actually true: because if the MitM can swap the addresses, he can probably also intercept the signed transaction and broadcast it himself... maybe only relevant if the tx is sent to the recipient through a different channel).  It also means that the recipient must actually act to broadcast the tx, which could be seen as actively acknowledging that payment was accepted.

Thanks.  This is the answer I was looking for!

This is interesting.   So as I understand it, a transaction can be created, however, unless it gets into the block chain, the funds aren't actually spent.   So this is one way to make a transaction reversible?

I wouldn't call it "reversible" since transactions don't really "happen" until it hits the network.  But yes it is more "flexible" than just broadcasting the transaction as-is.   Just like a check, no one should consider the transaction valid until it is submitted and "cleared."

The only problem with it is, it's very easy to accidentally invalidate this Bitcoin "check" because otherwise it would require locking coins in the wallet, usually an amount in excess of what the check is for (because you would have to lock the recipient amount and the change, which could be large and necessary for further transactions).  So I'm not sure how practical it is unless your wallet is low transaction volume and you expect them to be broadcast quickly.