With a DVB/Radio link to the network one could listen to transactions only to their address. You could think of bitcoin operated gas stations, bitcoin network-hubs in rural areas, micropayments to car-charging stations (all you need is power and a cheap DVB receiver to listen to the address "beacon" for a payment.
Now sending back transactions to the network is not covered, but can be done by using SMS or a small radio link to a local node. A bitcoin transaction is only about 64 bytes (!) so even a DTMF call or SMS should work fine.
A transaction send would look like this (normal TXid, in hex)
is just a transaction ID, not a transaction. A full transaction is longer. For example [1], a typical transaction with 1 input and 2 outputs, is 226 bytes.
The idea is that the payment receiver doesn't need to do it. The payee needs to have some kind of uplink (like a mobile phone, amateur radio, or anything).
There are mobile payment applications already, but they are doing it using centralized service and they need make deals with payment agents. With Kryptoradio it is possible to receive payments without any extra middlemen.
It's a huge amount of 'free' bandwidth, and a one-way WAN connection can still be useful.
It is only at the stage of a gimmick, or a proof of concept, but if the broadcast service could be relied upon long term, then it might greatly reduce the bandwidth and connectivity costs for simple Bitcoin-enabled devices.
It's misleading to think of it as only a one-way connection, because a user naturally creates a two-way channel.
Imagine a situation where a user sends a payment to the blockchain, via mobile internet, which is then picked up by the device. That is a de facto two-way connection. The user's phone (or whatever) would communicate with the device by a local area connection, such as Wifi, QR code, Bluetooth, even a typed code etc.
Obviously, devices could also have a low bandwidth uplink connection, such as 3g, but it's interesting to think about how it might still be useful with only a 1-way connection. It depends somewhat on the rate and structure of the blockchain data transmission.
Could it be used for things like vending machines perhaps? You would still need a cellphone to pay but the machine would only need an antenna and cheapish chip to make it work.
Except you wouldn't be able to generate valid blocks fast enough (confirm new transactions) unless you had massive hashing power (in which case you might as well go for a 51% attack against the Bitcoin network itself).
>Sure, if your willing to wait 20+ minutes to get your drink.
This is a fundamental misunderstanding people have about Bitcoin.
A bitcoin before a block confirmation ~ A credit card before 180 days.
There is a small possibility of "undoing" a transaction before a block confirmation, just like there is a small possibility of a customer doing a credit card chargeback before the credit card payment clears. However, it's a pain in the ass (even moreso with Bitcoin), isn't reliable with Bitcoin, and almost no one ever does it.
For small transactions like buying soda from a vending machine, waiting 2 seconds for the transaction to propagate is more than enough.
The only time I would ever wait for a block confirmation is if I was doing a transaction in the thousands of dollars range.
There are several ways you can implement this, but unless you wait occasional double spends are fairly easy to pull off. To put it simply unconfirmed transactions take a while to propegate and don't instantly decrement your wallet. True a single small transaction might not seem like much, but it's anonymous and even a small chance of success chance is going to be with it to some people.
PS: A 51% attack is only needed to counter confirmed transactions unconfirmed transactions have little protection and take a while to get confirmed.
Reversing an unconfirmed (0-confirmations) transaction is easy to do, with a supposedly 10-20% success rate, and doesn't depend at all on hashing power. Just broadcast a 2nd conflicting tx that pays a higher fee (most nodes won't re-broadcast a conflicting tx that comes in later regardless of the higher fee, but some will re-broadcast it).
But that's different from a double-spend, which is reversing a tx that already has 1+ confirmation, through a chain reorganization.
In the pilot we are just forwarding the transactions as they come. But in future we may send extra information if we receive a transaction trying to reuse already used transaction. That will help in the race condition you described: 1. wait for a transaction 2: wait some seconds if there comes an alert about other transactions trying to consume the same inputs.
That might help, but this is an issue which can be addressed after the pilot starts.
Double spends would be hard enough that it is not worth it for low-value transactions. The operator of Ghash would have a 30% chance of pulling it off, but that problem would be solved if hashpower/pool concentration gets solved.
You don't need lot's of having power a new transaction with a higher transaction fee can get you there ~10-20% of the time. For small anonimus transactions like a vending machine that's not a problem. Add a slick UI and an suddenly lot's of people are going for random "Free" soda.
I think there are a mix of reasons why existing double spends are working, certainly things have gone wrong and there are various ways to do it - e.g. Eligius does not follow the same rules as everyone else and that's exploitable by double spenders. However that's not fee related.
