Bitcoin Forum

I would like to gift bitcoin to friends/family without being able to rescind the gift but with them having no access to the bitcoin until it is has fully appreciated (ten years, let's say).

Can I do this with a bitcoin transaction or does it require a trusted third party to take custody of the bitcoin?

You can set a lock time, but it isn't as cool as you'd like.

The network won't remember your locked transaction for you, so you have to give them the raw transaction to be broadcast in the future.  Oh, and unless you delete the keys, you can always double spend it away during the lock time.

This is what cryptography is all about.  I'm excited to see a creative solution for this.

Could you elaborate? What would it take to implement this, so that it makes sense? I thought at least basic scripts are working (although I haven't seen them used).

I think a locktime would be the first basic smart contract. This is not entirely accurate then: https://en.bitcoin.it/wiki/Contracts, in terms of how much has been implemented.

This is something we have been working at also within the Bitcoin specie project.  A sort of nlock_time+BIP38 certificate for gifting / point-of-sale transactions.  It could also function as a sort of savings bond or bearer bond.
We are looking at having something ready early in 2014, but no formal announcements are made yet.

First, grab a new address.  Have them grab two new addresses.  Have them give you one of their new addresses, and the public key* to the other.

Use "bitcoind createmultisig 2 <yourpubkey> <theirpubkey>" to create a P2SH address that requires both keys.

Create a raw transaction to this address.  Don't broadcast it yet.

(At this point, the raw transaction that you are holding irreversibly transfers coins from your control to a multisig address that requires both of you to redeem.)

Create a raw transaction that redeems this unbroadcast transaction and spends it all** to their other address.  The eight zeros at the end are the lock time, in hex.  Edit them.  Less than 500,000,000 is interpreted as a block number, greater than or equal is interpreted as a unix timestamp.  Don't forget to convert to hex.

Locktime is ignored when all inputs are already final, so you need to find the sequence numbers of the inputs.  For this, you need to parse the transaction a bit, but this is easy to do by hand.  They are eight Fs at the end of each input.  Change at least one of them (to anything else).

Now decode your raw transaction to make sure you edited it right.  Verify that "locktime" is what you want, and that at least one vin sequence number is less than 4294967295.  Use signrawtransaction to add your own signature.***  Send it to them to sign.  Have them return the now fully signed transaction so that you can decode it again to make sure it is complete.

(This new transaction transaction can, when the lock expires, spend the funds held by the multisig without your help.)

Now use sendrawtransaction to broadcast the first transaction, and give the locked transaction to the gift recipient.

The final state is that the gifted bitcoins are now in a transaction that you can only spend by getting them to sign a new transaction, but they now hold a transaction that you've already signed that will allow them to spend it to their own wallet.

You can also do this all yourself, and provide them with the WIF of the two keys generated for them, along with the final signed transaction.  If you delete all traces of the privkeys and WIFs, you end up in the same place.

There are also variations you could do, like having them sign (or signing yourself if you are going that way) a second locked transaction that will allow you to recover the gift if not used.

*  As far as I know, there is no easy way to do this step.  If people are serious about doing this, I'll see about adding a getpublickey RPC command.  Use validateaddress (see below (https://bitcointalk.org/index.php?topic=391092.msg4221464#msg4221464)).

**  Try really hard to guess how much of a fee you'll need in the future.  Too low and it might never confirm.  Too high and you might be giving away a lot of money.

***  You can change the order here.  If you provide the redeemscript from the P2SH address created earlier, they can do the initial signing.

Edit 2013-12-30 16:20 - changed first footnote.  Thanks sipa.

There are so very many reasons for this, beyond just this application.

For some FUD fun, I'm trying to imagine the economic consequences if a holder of an enormous share of coins set such a condition and specified a final state for the coins at a time made public for all to see.  Meanwhile the world watches an ominous timer tick on and nobody can do a thing about it.

It's one thing when fontas claims there will be a huge dump in the trollbox.  Grain of salt.  It's another thing when a massive dump is guaranteed by cryptography.

If one of you Bitcoin coders could implement time-locked transactions in a fool-proof, rock-solid way, I'd gift 5% of my bitcoin to friends/family, and then send 90% of my bitcoin to myself at some point in the distant future to make sure I don't do something foolish in the short-term, like selling them in the dark days of FUD ahead. I'd keep 5% in cold storage to play around with.

I'd much rather trust a time-locked script (with an easy GUI) and the blockchain as a "custodian" of my bitcoin than a bank or a law firm or a hosted wallet or even a paper wallet that requires that I physically secure it.

Wow, thanks! but that is WAY over my head. I'd better go watch the Khan Academy videos. . .

Turns out I don't need to write getpublickey.  validateaddress already does it.

People will come up with pretty tools to make it easier as we go.  But for now, the guts are certainly here and do work.

This really can be done by hand though, if you have an urgent need to do it.  Decoding a transaction in hex by hand is pretty easy.  Just follow the docs (https://en.bitcoin.it/wiki/Protocol_specification#tx) and remember that each byte is 2 chars, and that you are counting in hex (in my example below, the pkscript length 19 is in hex and means 16+9=25).

And double check everything before you send anything.

01000000 - version
01 - vin count
 2084ba9f2f0f98bb - prevout hash
 1cf0320ee1c486b5
 9b6b79e243de7596
 d3e44fa087b597aa
 01000000 - prevout index
 00 - signature script length
 ffffffff - sequence
01 - vout count
 00e1f50500000000 - value
 19 - pkscript length
 76a91428f60d621b - pkscript
 5d07b9c2820c11cc
 c6d41146b53a3e88
 ac
00000000 - locktime

One of the problems someone at my skill level has is not exactly knowing what environment I need to be in to even begin to understand what you're going for.  This is n00b, but can you recommend a resource?  Competence is there, I just haven't really turned the corner on being able to look up what I need when I need it - so that I can manipulate things the way the heroes do.

I've been nagging at the idea for a bitcoin school.  I would pay for it.  I'm 2 years too late to the party and I want to chill with the cool kids so bad.

I'd pay in bitcoin for challenges you guys could write and just moderate passively.

The idea of a school is a good one.
It is something that could be attached to the conferences that are regularly scheduled all over the planet.
The folks that can teach are certainly there.  The facility is there.  It may make sense to do classes as an addition to those.

I agree.  GetPubKey would be a great RPC addition.  Also thanks for that walkthrough.  I may try this out on testnet and later with a token amount of BTC on main net.  I would caution anyone looking to "play" with raw transactions you can permanently lose funds by creating flawed raw transactions.  Use testnet, build testable software (even if it is just some scripts) to create the raw txs, and only move to main net once fully tested.   

Another great idea in this thread.  Maybe this platform (or one like it) could be leveraged ( https://www.hackerrank.com/ ) to support a Bitcoin challenge track?

Something that is a series of "courses" which starts with the basic like installing bitcoind, moving the data directory, configuring config file, etc.  Higher level courses could cover RPC calls, pywallet, creating watching only wallets.  Highest level courses could cover raw transactions, message internals, modifying the source code, etc.

So many ideas and so few people to do the meaningful and necessary things, this one... education for the motivated, is on the critical path.
Passion * Capability * Opportunity = success, we are short on the capabilities and long on the other ingredients.
This problem is not going away, and is going to get worse, so it is an opportunity worthy of some investment.

Take a look at my 741 mug.  I want to design all kinds of hardware for bitcoin, wireless analog type things. I try to soak up what I can, but I'm missing some basics still.  All electrical engineers are crappy programmers, but the heores here are on a level that is hard to just snap into, even for someone with some programming experience.

I would pay for a school, and I would pay to support a challenge series.

I would advertise it in /r/cryptomarkets, where I am moderator, to get others interested.  I can't be the only one who wants to know the protocol better.  I'm all ears on promoting an educational series for BTC, it's necessary or else the gap will just persist.  

On another note, this place is a desert for electrical engineers, and I can't seem to get many interested.  No idea why they aren't here.  Bitcoin isn't just cool for computer science, it's cool for communications.  Seriously, stunned that there aren't more wireless people here.

Well, I am planning on running a Bitcoin Experts table at the BTCMiami conference, just outside of the actual conference, so you don't even need a ticket to come see me and ask questions. I plan to have a few very basic things with me to demonstrate how bitcoin works, but can expand it into more of a training class type of thing, as opposed to just random questions people might have, like "how do I do cold storage, what happened with this country, what app can I use on this system" and so on.

I work at univ. of Fla, let me know if you want me to advertise your QA.

There's a place for questions harder than "what is a block". I personally would love a mathematical review of the cryptography takes place on the bitcoin network and what is possible to implement written in terms of functions and not in the context of computers only. This is so that I can extend the technology to a radio broadcast medium.

Good example is in my NFC thread right now on this forum. There's a way to step back, and view the problem if a merchant sale outside of the context of the existing bitcoin network.

How much information Needs to change hands (bare minimum) for a (type xyz) transaction?

What is the "laziest" exchange of information that results in a balance inquiry?

Obviously I also do want a conventional review of the code as well...and those are hard to do well when everyone shows up with a different level of understanding. I just attended a workshop intended to teach scientists how to use crystallography software called "quantum espresso." Some people just vanished during our terminal sessions because they were so underprepared. Others seemed bored.

I'm very supportive of a challenge series for bitcoin, that's how I learned python. doing puzzles online. With bitcoins it's also possible to incentivize success with rewards.

Anyway I am very serious about getting the word out at UF, especially around ECE so please follow up to this end is there is why way I can assist this effort. Once I receive the training, I'll teach others.

Can you clarify - a lock time is a piece of data stored (where?) that refers to a transaction that has not been broadcast?

What I think is more interesting is a TX that has been broadcast, but is somehow locked for a certain amount of time.  Which are we talking about?

The "lock time" is the value inside the transaction which indicates the earliest it can be included in a block.   The tx can't be part of the blockchain until that time because any block which contains a tx that exists prior to the locktime is invalid.

So what he is saying the network won't remember it for you, you will need to store a copy of the "signed and valid yet not yet able to be included in a block" transaction and submit it to the network AFTER the locktime has occured.

It would be useful to set a lock time of 100 years for everyone in the world except for a specified address, which could break the lock.   If one could do this you'd be able to pay people offline by generating a keypair, handing them a loaded paper wallet that's locked to everyone except the person you're trying to pay (who has provided a public key to the payER).

Is this already done?  I think it sounds reasonable.

Wouldn't you have to generate every possible bitcoins address that will ever exist in order to do this?

I'm not sure there is enough time or energy available to do such a thing.

I lack an understanding of how a lock time is specified.

So it locks certain keys, but everyone else can spend?  If that's the case, then a complimentary function would have the desired effect. Bitcoin school please!

I'm trying to think of a secure way I could run into you on randomly in the forest, where there is no wifi, recall I owe you 5 bucks, and pay you because I happen to have a paper wallet printer on me.  So I make a keypair, and say "here ya go.  The coins are allocated to the priv key printed here, which is not so private anymore, so good think I locked it out for everyone on the planet except you.  Have a nice day"  I'm probably missing something though.

As long as your friend can trust you not to double-spend the inputs before he can get back to a computer and broadcast the transaction, it would make a lot more sense to just generate and print out a raw transaction.  The raw transaction would be just as safe and secure as any other transaction that is ever broadcast on the bitcoin network.

Why would you have thought to "lock it out for everyone on the planet except you", but not thought to actually send the transaction at the time when you had an internet connection earlier anyhow?

Right, well I don't know.  I thought the locked TX is a TX that isn't broadcast so the network doesn't know about it.  Clearly I am still not thinking about this right - I did not think a connection was necessary.  What am I missing?

I'm very interested in trust free, in the forest payments and take stabs every so often.  

That's the thing, my friends are jerks.  lulz, but in seriousness...the situation I gave is a metaphor...replace friend with enemy and the situation is still interesting.  One must be able to pay their enemies too.

All transactions already have the property of being "locked out for everyone on the planet except you" where "you" is the holder of the private key.

Addresses don't have balances, and can't be locked.  The locktime field specifies the earliest time (or block number) that a transaction itself can be valid*.  The locking action actually comes from sending to an address that you don't have the key to, the locktime unlocks them later.  (Please see my long post earlier in this thread to see how it works.)

In your example, you would be better off just printing a signed transaction to one of their addresses.  If they don't have an address on them, you'd need to print out both a new private key, and a transaction that spends one of your coins to the address of the private key.

* And just to be clear because this is dev/tech, it must be paired with a non-maximum sequence number to work.

How trivial, but also ...wow, deep insights just now. Thank you.

The Bitcoin Specie project is also looking at this same use case.
We are looking at producing an attempt in early 2014.

So am I. See NFC transceivers thread. It has been written RFID encryption is not strong enough...I think this is foolish and true only if you're decisively unmotivated. Good luck.

Thank you!
And I agree with you, that the RFID is fine.   It is the implementations that are all horrid and have given it a bad name.  
Your project is not just good for Bitcoin, it would also be good for RFID, so I wish you very good fortune as well.
There is always some luck in innovation.
I don't think we will be using any NFC at all as our set of goals include utility in the absence of electronics, (and power).  So I am very excited about your effort and would be happy to collaborate.

Alright. PM me so I can learn about your skill set. It's just 3 engineers now for everything so we can use help.

I gained an understanding of locktime by messing around with bitcoind. Your explanation of it was really good. Still you don't know something until you see it right on the screen. I know as I must focus on circuits, other professionals would appreciate a software tutorial... especially EEs. We don't have to be able to write bitcoind from scratch, but I think we should know what the code says.

YouTube videos would honestly suffice! I would pay. If you aim this at a group of people actually capable of teaching themselves, but want to speed things up, it could be wildly successful. Think about it that way.

If the hardware developers are going to be shipping boxes with new firmware, it has to comply with bitcoin protocol which, as we saw in another thread, is roughly defined by the source code of satoshi itself.

So it has become quite obvious to me that I cannot even manage a project (to my satisfaction) without more intimate knowledge of the client. Simple as that.

Someone who knows a little but knows what they don't know, is worth much more than someone who knows a lot but thinks they know what they don't know.

I won't be answering any of the harder math, programming, and cryptography questions. If you want to come and help with that, that's be great, though those never seem to come up...
And yeah, if people at UF want to learn about bitcoin, by all means, tell them to come by :)