Altoidnerd
|
|
December 31, 2013, 03:19:52 PM |
|
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?
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
January 01, 2014, 12:23:45 AM |
|
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
|
|
January 01, 2014, 01:44:18 AM Last edit: January 01, 2014, 02:19:23 AM by 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
Legendary
Offline
Activity: 3472
Merit: 4798
|
|
January 01, 2014, 01:48:24 AM |
|
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
|
|
January 01, 2014, 02:15:20 AM |
|
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
Legendary
Offline
Activity: 3472
Merit: 4798
|
|
January 01, 2014, 02:47:37 AM |
|
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
|
|
January 01, 2014, 02:58:15 AM |
|
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
|
|
January 01, 2014, 03:01:32 AM |
|
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
Legendary
Offline
Activity: 1302
Merit: 1026
|
|
January 01, 2014, 03:54:57 AM |
|
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
Altoidnerd
|
|
January 01, 2014, 07:19:03 AM |
|
How trivial, but also ...wow, deep insights just now. Thank you.
|
|
|
|
NewLiberty
Legendary
Offline
Activity: 1204
Merit: 1002
Gresham's Lawyer
|
|
January 02, 2014, 09:18:21 AM |
|
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
|
|
January 02, 2014, 01:58:44 PM |
|
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
Legendary
Offline
Activity: 1204
Merit: 1002
Gresham's Lawyer
|
|
January 02, 2014, 03:01:38 PM |
|
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
|
|
January 02, 2014, 03:28:41 PM |
|
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
|
|
January 02, 2014, 03:37:16 PM |
|
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
Legendary
Offline
Activity: 1204
Merit: 1002
Gresham's Lawyer
|
|
January 02, 2014, 04:08:16 PM |
|
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
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
January 03, 2014, 06:21:34 PM |
|
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
|
|
|
|
|