Kryptoradio – A Bitcoin data transmission system | Hacker News Reader

Kryptoradio – A Bitcoin data transmission system

kryptoradio.koodilehto.fi

204 pointsmappum61 comments

This means parking meters, vending machines, laundromats, etc. can receive bitcoin payments without an internet connection. That is actually really cool.

Well, only if the transmission is signed & trusted. Otherwise, an attacker could just spoof a payment by transmitting a modified blockchain close to the payment terminal.

Also, things like DVB tuners are not exactly cheap enough to be integrated into many devices (though FM receivers, which may be used in the future, are).

>Otherwise, an attacker could just spoof a payment by transmitting a modified blockchain close to the payment terminal.

If the payment terminal used an SPV-like technology, the attacker would have to have a tremendous amount of computing power. This attack is not feasible, especially considering the relatively small reward of fooling an ATM or a parking meter.

Today. Parking Meters have a lifecycle of up to 25 years.

But since the meter would know the current difficulty level and with the auto-adjustment of difficulty to the amount of hash power in the network, the meter would be just as secure in 25 years as it is today even with incredible advances in hash speeds.

DVB-T tuners are pretty cheap because they're highly integrated and mass produced in huge numbers - you can get USB receiver dongles for under $10 in single quantities. There are even SoCs that integrate a processor and DVB-T demodulator on a single chip, usually used for stuff like set-top boxes.

>There are even SoCs that integrate a processor and DVB-T demodulator on a single chip, usually used for stuff like set-top boxes.

Are there any such chips other than the Broadcom chip that was announced last year?

Yeah, several companies make them, they're very popular in cheap set-top boxes. Having found what I think is the Broadcom press release you're referring to[1], the thing that's unique about their SoC is that it supports DVB-T2 which is newer and less widely used or supported. Looks like ALi have just announced a SoC for that too[2], though unlike Broadcom's it requires a seperate tuner chip.

[1] http://www.broadcom.com/press/release.php?id=s736006 [2] http://www.digitaltvnews.net/?p=24266

Oops, I read your first comment as saying "CPU, demodulator, AND tuner". Yes, there are lots of chips that integrate a CPU and demodulator, including the ultra-popular RTL2832U, very popular among SDR hobbyist (as combined with E4000 and other tuners).

The point of proof-of-work is that the attack you describe, "transmitting a modified blockchain", is very, very expensive. Essentially any plausible block is "signed & trusted" by the very-difficult partial-hash-collision embedded within.

In this situation, not really. Bitcoin's proof-of-work scheme means that if you see two different versions of the blockchain, whichever chain is longer will (with very high probability) be the globally-accepted version. But that assumes you have the ability to communicate with at least one non-malicious node.

In this case, there's a single communications channel that could be spoofed by anyone with a transmitter powerful enough to drown out the legitimate signal.

No, because proof-of-work prevents you from "faking" a blockchain. Let's say we are at block 100 and you would want to fake "the blockchain". You would have to fake a block every 10 minutes, but that requires mining, because you can't just make a block - it has to fit the previous one with the right difficulty.

You could stop sending new blocks, but that would alarm the endpoint because it will be stuck at block 100 (in our example).

The Proof-of-work scheme is pretty innovative.

It means if you could override the signal with your own AND had a lot of hash power, you could slowly drag down the difficulty of your fake chain and eventually it'd be easy to create. But indeed you must (assuming the device managed to see the real block chain at least once) do a lot of computational work to start with.

> Well, only if the transmission is signed & trusted. Otherwise, an attacker could just spoof a payment by transmitting a modified blockchain close to the payment terminal.

As noted in the article (under the "technology" page), signing is planned but not yet implemented.

> Also, things like DVB tuners are not exactly cheap enough to be integrated into many devices (though FM receivers, which may be used in the future, are).

What kind of devices are you thinking of? It seems to me that the most useful applications of this system would be for vending machines. A $10 DVB-T demodulator (at scale they can be had much cheaper than that) is a rounding error in the cost of those devices.

Not necessarily. If the installer of the machine checks that it downloaded the "real" blockchain, it would be expensive to forge new blocks to send to it.

Indeed, this frees us from dependence on highly priced internet in developed countries and has so much potential in emerging markets.

The blockchain is big and ever-growing. If people really start transacting, like hundreds of millions a day pay their parking with Bitcoin, imagine the size of the data. Plus, Bitcoin can't handle it now with the 7 TPS limit.

Discussions on Scalability have suggested an eventual goal of 4,000 TPS are entirely reasonable.

https://en.bitcoin.it/wiki/Scalability

Well, considering the size now with 7 TPS limit, 4K TPS (which is still lower than any of the major credit cards) will make things worse. 7 TPS is there for a reason.

According to the scalability document, VISA handles on average around 2,000 transactions per second

Burst capability is 10,000 TPS. I'm not sure how up-to-date this information is anyway.

The blockchain can be pruned.

If you are somewhere that network connectivity is an issue, there are usually free parking spots and no laundromats. I guess oasis vending machines could feasibly be an issue, but you're now hoping that some niche market solves some of bitcoin's problems around being a better solution than existing options.

Cryptocurrency's design targeted the libertarian dystopia related to the interdependent nature (and potential abuse) of governments and their currencies. Given that the dystopian context doesn't exist strongly enough, other options will continue to have advantages within the current context.

You're more likely to show benefits with this when you can provide oppressed peoples' crypto-wallets with balances that can be converted into subversive tools. This, of course, will gain more of certain types of attention than a young currency could want.

Paying for parking is easy as it is. Same with paying to wash clothes. If you can't get cities and coin-op owners to upgrade to card swipe technology, good luck with selling them on immature digi-currencies.

Cryptocurrency needs to think less about catching up in various verticals and more on creating the killer value app... and the problem is nobody is seeing big $'s around the things that today's currency transfer technology has trouble with. We're on the cusp of IoT. Internetless internet-based currency?

Talking about that, Can anyone please transmit wikipedia via long wave radio? It would be interesting in censor states. Hiding wikipedia in tv/movie firmware would also be a possibility.

We can do it. It's just data. Of course long waves carry very scarce amounts of traffic. DVB-T or even better approach would be using satellite. There are digital satellite technologies like DVB-S which could carry that kind of data. It's only a financial issue.

It just moves the thing that gets censored from the website itself to the equipment needed to receive it.

Which is infinitely harder for authorities to control.

How wikipedia is different from any other website useful for victims of police state?

It's an encyclopedia of everything.

Thats all good and gimmicky but can you tell me: the 1-way connection offers any value to anyone?

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)

  a9d4599e15b53f3eb531608ddb31f48c695c3d0b3538a6bda871e8b34f2f430c

That would be

  76816061505687581068522220805344294890167166251289478281934616246172205973504

in DTMF. Would take about 15 seconds to complete (http://www.audiocheck.net/audiocheck_dtmf.php)

    a9d4599e15b53f3eb531608ddb31f48c695c3d0b3538a6bda871e8b34f2f430c

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.

[1] https://blockchain.info/tx/2e395e9567bd43d3eecd7a6bdf990387d...

Why not just send the confirmation back by SMS?

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.

That would require trust - in the form of the SMS provider. No way to verify that SMS is valid, it could have been forged.

The proof-of-work blockchain transmission means it's the real and proper blockchain and is valid.

>Would take about 15 seconds to complete

That's unfortunately not sufficient at modern transaction rates. Is there any reason you chose DTMF in particular?

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.

And I just need a tiny DVB-T transmitter to feed my own blockchain to it. I like that idea of yours! :P

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

If only there were some way to cryptographically sign stuff...

That's an incredible idea.

Sure, if your willing to wait 20+ minutes to get your drink.

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

The economics and technicalities of this are analyzed extensively in the latest Ethereum blog post https://blog.ethereum.org/2014/07/11/toward-a-12-second-bloc...

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.

That's the type of attack I was thinkining of, but if your not calling it a double spend what's the terminology?

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.

Yes, for the same reason a radio broadcast does.

Distribute valuable information (mined blocks and verified transactions) with a nearly constant cost in relation to the recipients.

Fascinating idea. In the areas that this would work, would it not be simpler to just use a normal cell phones data connection or SMS?

Say the blockchain's growing by a gigabyte a month.[1] I don't think SMS can support that much, especially times so many devices. Using a tv signal is more robust - you can support millions of devices, and transient 3G network failures will have less or no effect.

[1] I estimated. http://blockchain.info/charts/blocks-size

But the parking meter (etc.) doesn't need to handle the blockchain at all. It could use the SMS to communicate with a shared parking meter bitcoin transaction server. That said, broadcasting the blockchain is useful.

If you stick to centralized solution then that would work nice and might be good enough. However Kryptoradio allows to do it by just listening incoming transactions and blocks.

The idea is that a lot of devices wouldn't need a two-way connection, rather they could confirm payment with only a downlink.

Deleted comment

Right, and the full blockchain via radio plus SPV via the internet would allow full nodes to use this without trusting the centralized broadcaster.

I had a similar idea like this, but using shortwave instead of DVB.

Are we going to witness another Clinkle sotry (http://www.businessinsider.com/inside-story-of-clinkle-2014-...)?

Reply on news.ycombinator.com