Is it possible yet to send bitcoin with a defineable time (or block #) delay?

[Altoidnerd]

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.

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?

[1714770611]

1714770611

[DeathAndTaxes]

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.

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.

[Altoidnerd]

The "lock time" is the value inside the transaction which indicates the earliest it can be included in a block.  

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.

[DannyHamilton]

It would be useful to set a lock time of 100 years for everyone in the world

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.

[Altoidnerd]

It would be useful to set a lock time of 100 years for everyone in the world

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.

[DannyHamilton]

It would be useful to set a lock time of 100 years for everyone in the world

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?

[Altoidnerd]

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.  

[Altoidnerd]

As long as your friend can trust you not to double-spend

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.

[kjj]

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.

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.

[Altoidnerd]

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

[NewLiberty]

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.  

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

[Altoidnerd]

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.

[NewLiberty]

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.

[Altoidnerd]

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.

[Altoidnerd]

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.

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.

[NewLiberty]

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.

[Rassah]

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

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