Topic: Is it possible yet to send bitcoin with a defineable time (or block #) delay? (Read 5342 times)

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

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 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.

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

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.

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.

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

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

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.

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.

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.  

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?

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.

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.

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.

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.

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?

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.

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.

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.