Topic: Why does "createrawtransaction $(decoderawtransaction $hexString)" not work? (Read 2474 times)

It looks like Peter Todd understood why this is a good idea:

https://twitter.com/petertoddbtc/status/510360423770898432
https://github.com/viacoin/viacoin/issues/5

Locktime was initially designed to be used with transaction replacement---the replacing of one version of a transaction with another.  This is a feature used today in "contracts" such as a micropayment channel.

Obviously, if time locked transactions are added to the block chain, you can't do transaction replacement.

Now my question: why would you want to irrevocably pay someone but not let them spend the money until a later point?  I kind of like the current method where I can give someone a time locked transaction but rescind (double-spend) it prior to the locktime maturing.   With this method, you can accomplish everything on your list except for #4:

1. No need for a separate service: the time locked transaction can be stored in the same wallet as the receiver's private key.  If you lose your private key, then the transaction is worthless to you anyway.

2. No risk of the spender double-spending if you use a two-hop transaction where the first transaction goes to a 2-of-2 multisig output that has one key each from the spender and the receiver.

3. Only one private key needs to be kept secret if the spender deletes his private key.

4. (You do not get protection against the transaction format changing.)

5. Simple UIs have already been written for micropayment channels which use time locked transactions.  For example: http://www.youtube.com/watch?v=r0BXnWlnIi4

It wouldn't matter much if some clients didn't support it once the majority of nodes supported it. I assume most clients use listunspent, which arguably shouldn't return such locked outputs anyway.

My reading of the wiki is that this is indeed what locktime is for, but it's broken:
https://en.bitcoin.it/wiki/Contracts#A_warning_about_the_mempool_transaction_replacement_mechanism , and Flynn has pointed out how absurd the alternative is.

Probably because some clients may not code it as such, and just allow people to spend it. Locktime is not designed for what you want to do.

I was pretty disappointed to see that this doesn't work. I expected a transaction with a locktime in the future to be broadcast and confirmed, but that the outputs wouldn't be spendable until the locktime was reached (except the miner fee). This seems to have many advantages:

1. No need for a seperate service to store such transactions, they're in the blockchain
2. No risk of the sender double-spending his part of the transaction
3. Only one private key must be kept secret: the recipients
4. No danger that the transaction format may be changed in the future, making the transaction useless
5. Much simpler end-user experience - the coins appear in the wallet, but aren't spendable. No need to fiddle with transactions.

Can someone explain why it can't be implemented this way? Every node would have to start checking whether inputs come from transactions which haven't reached their locktime, but this seems fairly minor.

Well, if bitcoins just accepted transactions that were in the future, there's your setup.

Unfortunately, people have to ruin the fun and use it for DoS attacks (I believe that's why it's disabled?).

Actually, several services like this could should be set up, all of them broadcasting the same transactions (at about the same time, when they'll be accepted)  - If one of them fail, it doesn't matter because the others would do the job. What should be done is some kind of replication server to do that job... so all the servers stay synchronized and maybe more importantly nobody can't put a threat on a server's owner to make a transaction disappear as an exemple for financial reasons...

Ho damn, I just reinvented the peer-to-peer, ho well ...

But then people have to trust me to broadcast 'em, isn't the whole point of bitcoin peer to peer implementations to not rely on any single person  

Anyway, it'd be very simple to do, I would do it, but, the issue is that I couldn't guarantee uptime of months on months (Which, I know some people would want, to say "I want this broadcasted in X months/years"), so, I'm not going to.

Fair enough.  Although now if you get bored, you can be the person who codes up a simple web service that stores locktimed transactions and broadcasts them when appropriate.  :-)

Nothing I can't do now, but, now it requires the other party to know what they're doing to be able to broadcast the transaction themselves, before, they'd be able to just look it up on blockchain.info, see "Oh, unless Automatic changes his mind, you'll get your money on Feb 20th", now, it's "oh, here's some really complicated string of numbers, now what I need you to do is save it, and, remember it, then, on the 20th, I need you to broadcast it.".

Not being able to broadcast it before the effective date may be less cool, but it's not any less functional.  I use locktime to send money to myself in the future---sort of like buying myself a savings bond.

The sequence number lets you publish multiple versions of a transaction. The network is supposed to drop a pending transaction when another transaction appears spending the same input but with a higher sequence number.  Sequence number and locktime are both currently used for payment channels as implemented in bitcoinj.  See the following link for details:

    https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

I'm curious: what cool thing did you want to do with locktime that you can't do now?

If you can't actually broadcast the transaction, may I ask what the point is? Just to simply give it to the other party and be like "Yeah... can't currently send it yet, but, heyho, you'll be able to in X days/blocks"? Seems a lot less cool than actually broadcasting it.

EDIT:- And what's the point of sequence then? If you can't even broadcast it till it's valid anyway.

I assure you, you can set sequence to non-max. Here's a locked transaction I sent myself last week:

    https://blockexplorer.com/rawtx/5af2104b1d7f9524f9bb2d5b81e79e7d6e3b21cb5552e31a96a24a7adc3344c7

Note that since early 2013, the memory pool will not accept non-finalized transactions in order to prevent DOS attacks. This may be the source of your error. Try sending the transaction when the locktime/lockblock is in the past.

Automatic:

I just saw your post. The reason your transaction went through immediately was that the sequence number of all inputs was set to the maximum value (4294967295), indicating the transaction was finalized and the locktime didn't apply.

Changing any sequence field to any number less than the maximum will prevent the transaction from being entered into a block until the locktime (or, in your case, lockblock number) passes.

I got tired of changing locktimes manually, so I wrote a quick shell script that changes the locktime to an arbitrary date and sets the sequence number to zero. The script then does some quick validation of the resulting transaction to help prevent me from doing anything simple.

I added some comments to the script to help explain what's going on, but let me know if you have any questions.  Note: I haven't tested it on multiple-input transactions.

Point I'm trying to make it less that, and more the fact that the input for 'createrawtransaction' is different than the output of 'decoderawtransaction', so, I'm confused on how to do this.

EDIT:- after learning that the encoded transaction is just a concatenated string of the data in the JSON fields (Source here) and not some super duper l33t h3k3r string that only the jedis of Bitcoin can decode, I realized I could just manually replace the 'locktime' field, and, that's what I did:-

is equal to:-

Time to sign this, and, broadcast it, and, see how it works!

EDIT:- Had to change input address due to the fact that my client (Armory) was complaining about the wait time, and, my laptop (offline wallet) is in the other room, so, signed with an online wallet:-
https://blockchain.info/tx/54fc5ba26ddee61c1338a7196b58a0c954039c3f08408a497ba4f79d80f61d98

Let's see if this takes till block ID 284300 to confirm.

EDIT2:- Nope, didn't work at all:-
https://blockchain.info/address/1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa

Managed to receive, then spend my BTC before block 284300, I must be missunderstanding this.

Proof I didn't fuck up:-
https://blockexplorer.com/rawtx/54fc5ba26ddee61c1338a7196b58a0c954039c3f08408a497ba4f79d80f61d98

>"lock_time": 284300,

I think there is problem in txid, txid is sha256 hash of all transaction.
You made changes in transaction, so there is new hash.
Also, there is other format of createrawtransaction
bitcoind createrawtransaction '[{"txid":"2150f5a18448b5cafe5f0a41d8c61606178d52fca52a8e53f486a288dd433caa","vout":0,"locktime":2}]' '{"1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa":0.01}'
https://people.xiph.org/~greg/escrowexample.txt check this

Inputting the output of "decoderawtransaction" into "createrawtransaction" results in an error, I want to make a small change to a transaction before I sign it manually (Add a "lock_time", I want to see how it works), but, I can't seem to be able to do it.

Here's my hex string:-

decodes into:-

Piping that back in as:-

Results in "Error: Error parsing JSON:{txid" or "Error: Error parsing JSON:{", depending on if I copy it formatted or all on one line. The format of createrawtransaction (createrawtransaction [{"txid":txid,"vout":n},...] {address:amount,...}) is obviously different to the output of decoderawtransaction, so, what's the best way of doing this?