You can already do that (well, if the features were re-enabled).
Send coins to a recipient as usual. The recipient creates a tx with a nLockTime in the future that sends them back to you, but doesn't broadcast it, instead they just give it to you out of band (eg via email).
Now wait. If after the time period is nearly up the coins weren't spent, broadcast your reclamation tx. Once nLockTime passes the coins are yours once again.
Broadcasting the reclamation tx prevents the owner spending the coins (it'd be a double spend so will be rejected). But the reclamation was created by the owner of the coins, not you. If you broadcast it before the time is up, the real owner can create a new version of the tx with a higher sequence number and broadcast it to claim the coins for good, overriding your reclamation tx.
In this way there's no point trying to reclaim the coins unless the recipient has really gone away for good and won't block your reclaim attempt.
The transaction of your coins for their promise to return your coins is not atomic. And thank you for the other part. I had been wondering about nLockTime and sequences for a while now, but hadn't dug into them. But now I know. Another nifty gem hidden in the bitcoin design. |
|
|
|
I just realized something. All of the current money systems in the world today are already more uncertain than bitcoin will ever be. Bitcoin actually gives us boundaries on the uncertainty which do not exist in the real world. The amount of bitcoins that might potentially show up on the market tomorrow is strictly limited by powerful mathematics. The amount of dollars (or whatever) that might potentially show up on the market tomorrow is limited by human discipline. And we know which one has a better track record.  |
|
|
|
|
While I was driving today, I had some thoughts on what exactly was needed to get my hardware wallet project talking to the client. Might work for other types of smartcards projects too.
I also had the bright idea of letting the client act as a stand in for a hardware wallet.
Step 1. Add some new methods to the JSON RPC API. I think I can get by with just 4, but I may have missed something. acceptPublicKey tells a node to add a new public key and include it in balance calculations. getPublicKeyTransactions tells a node to return all transactions involving a given public key. getPaymentRequest tells the node to give it any pending payment requests. returnPaymentRequest returns the signed transaction to the node.
Step 2. Add UI/config file support for these calls. A set of options to specify a remote JSON server to connect to as a client. An option to tell the client NOT to generate keys. A checkbox on the payment page to tell the node to queue up the amount/address pair for delivery to an external device in response to a getPaymentRequest RPC call. A button to tell the client to ask the other server for transaction requests. A dialog to display and request confirmation/deletion of queued requests.
At this point, you could have two computers running bitcoin. One on your main box that has no keys and is unable to send any coins by itself, and a second box that does not connect to the network ever, but only talks RPC to the first box. All keys are on the second box, so all payments must be relayed through the JSON RPC service from the first box to the second.
Since the second box is on the network too (or it wouldn't be able to talk to the first box), won't it get infested too? Yup, and that brings up...
Step 3. Implement JSON over serial. Could be actual serial, could be serial over bluetooth, could be serial over USB, could be a terminal program on each box with the super paranoid user relaying commands back and forth by retyping them. I think we would need to extend the JSON spec, since it doesn't seem to contain any provisions for in-band authentication, and we won't have access to the HTTP layer doing it for us. I propose that each string be followed by a hash of the command + password.
Step 4. Implement a security system that allows the developers (or the use, I suppose) to allow/disallow certain RPC to come in from or go out to certain interfaces.
Step 5. Build hardware that talks this protocol over various forms of serial.
I think that this approach has a bunch of advantages. First, it allows everyone with a junk box sitting around the ability to set up a secure offline wallet without needing any special hardware. Second, it allows debugging to take place on computers which have excellent debugging tools, at least initially. And when we get to the step where we are working with hardware, we will have a protocol to target that is known to work.
|
|
|
|
Ahh, found it in the btcguild thread. Does your node (the client software on your computer) have the entire block chain downloaded and processed? It won't show your balance correctly if it isn't done.
You can also go to bitcoin block explorer (google it) and search for your payment address.
And yeah, the payments are only down to the hundredth of a bitcoin, which is a bit silly. I don't know why he hasn't changed that yet.
Because older bitcoin clients don't support it and I believe behave badly if such a transaction were to come in. So, they pay to the bit cent. It is not as if you have lost the remainder, it just is not accessible without additional mining or waiting for the day when it is decided that everybody should have upgraded to a client that supports this and all pools use a daemon that is capable of the same. If you note, the bitcoin client is BETA, although a working beta and it is version 0.3.23. If the version were 1.0.0; then I expect all features expected to be "common" will have been out for long enough and enough notice given that such a switch over can be made. Until then, wait it out. Consider how much that "change" is worth at the moment and it probably wasn't worth the time to post. In any event, it is still your bitcoin fractions [unless the pool closes .. not sure what happens in that case, but that is not an imminent possibility even in the slightest] and you will either eventually get them or it is a little support for your next mining venture with the pool. Find a pool that sends out beyond the bit cent and use it if you can find one. |
|
|
|
Hmm. Think I found my hardware. Sansa Fuze - $50 on Amazon ARM9 based system on a chip (similar to the hammer I linked earlier) - up to 250 MHz, with 320K RAM on chip. 8 MB SD RAM Couple gigs of flash, and microSD socket for backups. Has a method for unbricking. |
|
|
|
That's fine, no one is going to force you to. But some people will find it useful.
This is a design discussion, we're trying to evaluate what would work best for the average user, it's not about what I want to use. My question is why would people find this useful if they can get the same functionality from a device they'd need anyway? Any chance you could find that reference? I would love to see it, but searching for "hackable mp3 player" doesn't turn up the sorts of things I'm looking for.
Sure: http://forum.bitcoin.org/index.php?topic=17919.msg227691#msg227691By the way, I am actively working on the hardware device route. I know what capabilities it is going to need, and what the communication protocol is going to look like, but I haven't yet found a hardware platform that is both simple to develop on and capable of doing the crypto.
What about the cryptocards like this? http://www.gemalto.com/products/top_javacard/download/TOP_DL_v2_Sept10.pdfNot sure it has the exact curve bitcoin uses, but it's getting pretty close. But they don't need the hardware device if they use an online service. These are competing options, not a decision that must be made once for all users at all times. Thanks for the link. I'll check those out. Hopefully one will be suitable. I may get stuck with a Java device just for price reasons, but I personally despise Java, so I'm looking for other choices. This would totally work, but is a bit expensive, and probably FAR more capable than we need. |
|
|
|
Damien, if they were rounding, my .119x would have been .12 don't ya think? I believe they are truncating at two decimal places, even though I select to remove all decimals.
I'll have to pay attention next time, to see if my balance beyond the dy-bit remains in the pool account. It is a learning experience, though.
kjj, deepbit, twice actually. I think I see your point.
Ahh, deepbit works the same as btcguild. Makes sense, as deepbit is even older. There is a historical/technical reason for it, but I don't recall what it is exactly. They aren't rounding, they are just truncating. The remainder after truncation remains in your account with the pool. |
|
|
|
Waiting for bitcoins II.
And the initial distribution for bitcoins II will be what exactly? |
|
|
|
the early adopters have used the deflation argument not to better everybody, but to enrich themselves. It has encouraged ridiculous speculation that is harmful and driven vendors away.
I haven't read anything in these forums by 'the early adopters' that supports what you say. They say deflation is good. OK, duh. They say that speculation isn't a goal, but it's inevitable. And as an austrian, how the hell do you know how much speculation is ridiculous? (Where is that secret measuring rod located?) I've listened to sefbot and whatch all 8 hours of the bitcoinshow, which is like an infomercial for bitcoins. In all the blog pieces that are fed to the new outlets they write they downplay the initial wealth distribution like it somehow is irrelevant. As an Austrian, its ridiculous to have daily speculation in a service that you want a vendor to use for everyday transactions. Without the vendors the service usefulness is that of a casino. The initial distribution is irrelevant. Also, what do you mean by initial? Do you mean, like really initial, the first block reward? Or do you mean the last block reward which won't happen for a century? Or do you mean some block in between the two? Which one? Justify your decision for which magic block is the final block of the "initial distribution" period. And are you kidding about the speculation? Speculators are everywhere. There is speculation in everything all day, every day. Are you sure you aren't really concerned with volatility? If so, isn't the volatility really caused by the relative smallness of the market? |
|
|
|
I'm not sure it's worth going through all this, risking small transactions, getting telephone calls, relying on a 3rd party site,
That's fine, no one is going to force you to. But some people will find it useful. Someone mentioned that you can hack a $20 mp3 player and install your own software. It's already got a display, input device and usb plug.
Any chance you could find that reference? I would love to see it, but searching for "hackable mp3 player" doesn't turn up the sorts of things I'm looking for. By the way, I am actively working on the hardware device route. I know what capabilities it is going to need, and what the communication protocol is going to look like, but I haven't yet found a hardware platform that is both simple to develop on and capable of doing the crypto. |
|
|
|
Ok so I just need to run the bitcoin client for ages?
Just until it catches up to the block that has your transaction in it. |
|
|
|
I have an Economics Degree From Sydney University
The reason all the early adopters - read people with a shit load of bit coins, don't want to talk about the fact bitcoins is designed for deflation is because what it really means is this.
Another reason you shouldn't mention that you have an econ degree: How in the heck can you have an econ degree and at the same time fail to understand the perceived benefits of a deflationary currency? It's odd to me that someone with an econ degree can have such a lack of education on monetary theory. The only person demonstrating a lack of understanding is you. I'm making no statements about the perceived benefits of a deflationary currency. These threads are clearly not a place to discuss bit coins they appear to be a bunch of insecure people looking to get rich. I'm going to find a serious forum on bitcoins - does anyone have any suggestions? Or maybe I'll just go back to the white papers. You can all just stay here and debate the 'perceived' benefits of ripping people off, the rubbish value of education and how it doesn't matter if something is fair. What a crowd. Sorry if I've included some people unfairly in this description. Shit, I think I missed something. Who is getting ripped off? |
|
|
|
|
Most nodes won't even bother relaying a transaction that involves an input that has already been redeemed, so it will be difficult to get your second spend out to enough miners. Also, having some fraction of honest miners that are unwilling to rewrite transactions for money will make the attack much less likely to work, since the mercenary miners are also facing the risk that their work will be wasted if someone else wins.
|
|
|
|
Looks like the two approaches are completely different.
One doesn't require the user to have to buy/build any specialized hardware. The other doesn't require the user to rely on an external service.
The bitcoin world is big enough for both approaches to make sense at different times or to different people.
And I must say that after looking into actually implementing ECDSA on tiny hardware, I'm really, really warming to Gavin's idea.
But there is no approach in which you only need an external service and no external device. If the root-kit has control of your computer, you can't trust anything on the computer, not even an https connection to a trusted server. How will you confirm the transaction? Or is the root-kit confirming it for you? Or are you confirming it, but to the wrong address? I think the idea of an external device is a good one, since it's much easier to secure than your home computer. You don't have to implement ECDSA on tiny hardware, there are already smartcards available with this capability. You don't confirm the transaction. What happens is that the service fails to confirm bogus transactions made in your name by your (pwn3d) computer. |
|
|
|
Hi, I was following the thread "Official Open Source FPGA Bitcoin Miner (Smaller Devices Now Supported!)". Unfortunately I am a newby and cannot post over there, now I do it here: I have found a standalone FPGA board with ARM linux system incl. network that is probably not so far from being competetive in the MH/$ region: http://www.dinigroup.com/new/DNDPB_S327.phpIt has 27 Cyclone III with 120K LE. From the above mentioned thread you can get a full SHA256 pipeline into ~75K LE running at 100MHz = 100MH/s. 27*120K LE = 3240K LE => 4.3GH/s Probably with less than 150W power consumption. VHDL code is available from the other thread, as its linux, one of the available miner cores should be easy to adapt. Price: ~21K$ :-( The FPGAs alone should be somewhere in the range of 8K$, so there is probably potential for a price reduction, if we buy enough of the boards. With power consumption becoming more and more important (in Germany), anybody interested in buying some boards? Of course an ASIC solution is far superior, but will require much more work and cost upfront. Your math is off by a bit because you can't split cores. If a core takes 75K LE, you don't get three of them by joining 2 chips with 120K LE each. You get 2. So, 27 chips would give you 2.7 Ghash/sec instead of 4.3 Ghash/sec. I don't know how that factors into your projections. |
|
|
|
|
Sure it could. But it probably won't. At least not all stolen coins. An exchange blacklisting coins stolen from themselves or their customers is slightly more likely, but not by much.
|
|
|
|
What the hell is a Nebbie? or a Nebie?
Also, how can anyone possibly look at these forums and pretend that deflation is a big secret that we are trying to hide from the masses? You can hardly swing a cat in here without hitting a dozen threads on the subject, including the one and only sticky topic in the Economics forum.
Why are people trying to suppress the point that the system is unfairly designed?  The facts are plastered all over these forums, as are all of the opinions for and against the system as designed. I still don't see how you can continue to claim that there is some sort of suppression going on. You are free to post your opinion that the system is unfair. Other people are equally free to disagree with your view, and to post their rebuttals. Is that what you mean by suppression? Are we suppressing you by posting our disagreements? Yes I can see that. i went straight to the economic forum post and the first one was basically everyone shut up about deflation, this is the final word, anyone who asks you about it - just tell them this is your answer.... I started thinking.... why? I quote the post in my kick off thread. It is mostly because we are sick of having to read a dozen of these threads every day. You don't need to trust me when I say that it has all been said here before (and many times). You can check for yourself. Personally, I would love to hear a novel argument against the design. But that never happens. Instead we get hundreds of people, none of whom ever bother searching or even just clicking on any of the many other topics on the issue, and they always end up posting what amounts to the same three tired arguments over and over again. #1 - Deflation will benefit other people more than it will benefit me. #2 - Inflation causes prosperity, deflation causes ruin. #3 - We will run out of money. By the way, I have no power or authority on these forums. When I saw "we", I mean the people that disagree with the deflation = evilz theory, not the board moderators, but considering the sticky, I suspect there is some overlap. |
|
|
|
I look forward to finding out what you hope to accomplish with this.
Shoudn't be more than a few days after I figure this bit out... The data field will be unique, at the very least to the server and block in progress. You can record that with the server it came from. Or, since you are changing both the proxy and the client, you could just have the proxy add a field that just says what server to give the work back to, and have the client return that when it returns the candidate hashes.
So the 'data' field that the miner returns is somehow related to the 'data' field in the getwork response. But it couldn't be the same or the server already has the block solved. Is the data field just the block header with the nonce altered to produce a valid block? Yes. The server sends the data block to the client with the nonce field set to 0. The client iterates through the 2^32 possible nonces, checking each one. If it finds one that meets the target, it sends the modified block back. There are circumstances where the server can send the exact same block out more than once, but this is rare, and you can't do anything about it until the node software is fixed. But, each node will have a totally different coinbase transaction included in the Merkle tree, so you will never get the same data block from two different servers, allowing you to always identify which server gave which work. |
|
|
|
|
Looks like the two approaches are completely different.
One doesn't require the user to have to buy/build any specialized hardware. The other doesn't require the user to rely on an external service.
The bitcoin world is big enough for both approaches to make sense at different times or to different people.
And I must say that after looking into actually implementing ECDSA on tiny hardware, I'm really, really warming to Gavin's idea.
|
|
|
|
|
Show Posts
