Live data from Hacker News

The Bitcoin Piñata

ownme.ipredator.se

21–30 of 112 posts

Re: The Bitcoin Piñata

#21
post #18
post #17

Suggestion: add an endpoint on the piñata that proves it has the private key. You can do this using Bitcoin's sign message method.

that wouldn't help - would it? any owner of the bitcoin secret can sign this message and include it then in the pinata... for online signing we'd first need to implement the bitcoin protocol... or am I getting something wrong?

Yup, you'd need to implement the Bitcoin protocol and load the private key and sign all the messages the echo endpoint receives.

Re: The Bitcoin Piñata

#23
post #18

Earlier quoted context omitted.

that wouldn't help - would it? any owner of the bitcoin secret can sign this message and include it then in the pinata... for online signing we'd first need to implement the bitcoin protocol... or am I getting something wrong?

Yup, you'd need to implement the Bitcoin protocol and load the private key and sign all the messages the echo endpoint receives.

And even then, you couldn't prove the piñata wasn't only proxying the replies from some other server.

Re: The Bitcoin Piñata

#24

Probably want to also go ahead and catch up on the TCP/IP stack; the pqwy/mirage-tcpip repo is some 232 commits behind mirage/mirage-tcpip, and is missing fixes for things like https://github.com/mirage/mirage-tcpip/issues/56

you're looking at the wrong branch... https://github.com/pqwy/mirage-tcpip/tree/pinata

Re: The Bitcoin Piñata

#25

Probably want to also go ahead and catch up on the TCP/IP stack; the pqwy/mirage-tcpip repo is some 232 commits behind mirage/mirage-tcpip, and is missing fixes for things like https://github.com/mirage/mirage-tcpip/issues/56

His master branch isn't uptodate, but the pinata branch that's deployed is tracking the head of mirage/mirage-tcpip. See the opam manifest here: https://raw.githubusercontent.com/mirleft/btc-pinata/master/...

Re: The Bitcoin Piñata

#26
post #25

Probably want to also go ahead and catch up on the TCP/IP stack; the pqwy/mirage-tcpip repo is some 232 commits behind mirage/mirage-tcpip, and is missing fixes for things like https://github.com/mirage/mirage-tcpip/issues/56

His master branch isn't uptodate, but the pinata branch that's deployed is tracking the head of mirage/mirage-tcpip. See the opam manifest here: https://raw.githubusercontent.com/mirleft/btc-pinata/master/...

You're right - mea culpa.

Re: The Bitcoin Piñata

#27
post #10

Earlier quoted context omitted.

Even less technical: A bunch of people write crypto software, and want to find out/demonstrate how secure it is. They do so by setting up a system that will transfer ~$2k worth of bitcoins to the first guy who breaks it.

> "and want to find out/demonstrate how secure it is" As the page (and my post) emphatically state, this contest cannot prove anything about how secure it is. That distinction is really important.

If you take as axiomatic that all security measures can be broken, then you can measure those security measures by the cost of breaking it.

You could measure the amount of time it takes for someone to break this security and grab the cash, but that only provides you with one datum. To really show how secure it is, you would also need to provide a $1000 prize, a $500 prize, a $250 prize, a $125 prize, and so on, all with equally strong security.

Then you start the clock. After the first prize is won, you put out the second prize and start the clock again.

Even if the winners don't share their methods, you can determine how long it took to claim the biggest prize, and compare with the length of time it takes for subsequent lesser prizes. A reduction in the interval spells trouble for your security method, because the attackers found an easier way to get in.

You can then determine the general level of effort required, when people finally stop taking the otherwise free money. If the $125 prize is claimed, and the $62.50 prize is not, you can assume that it costs between $62.50 and $125, plus a certain amount of time, to break your security.

As long as whatever you put behind that security is worth less than that amount of time and money, it will probably be safe from random attackers. Unlike an in-home safe or a bank vault, you can't take calipers and measure the thickness of the walls, to calculate how long it would take to cut through.

This contest doesn't prove anything, but it does suggest a guideline. If no one takes the $2000, then as long as the expected value of a random attack on you is not higher than that, you can feel safe using it. The problem is that it doesn't take much to rise above that amount. Late model car? Nice house? Taking an actual vacation? You're worth at least a spear-phishing attempt.

Re: The Bitcoin Piñata

#28
post #2

Can sombody explain this in a bit less technical terms?

The challenge is to present a certificate that the pinata interprets as being signed by the CA at the bottom of the page. If you succeed in doing so, you will be given the information required to transfer all of the BTC out of the address listed on that page.

Aaah, but you can try to do soooo much more!

You can try to confuse the ASN.1 parser, or even the protocol level parser.

You can try to defeat certificate validation logic.

You can try to get handshake state-machine do an illegal transition.

You can try to smash its memory and either read it or get your code into it.

You can try to defeat its RNG.

It doesn't let you do adaptive-plaintext attacks, but everything else is up for grabs. And you don't necessarily have to wait for it to politely send you the bitcoin key - it's somewhere in there, in memory!

Re: The Bitcoin Piñata

#30

Earlier quoted context omitted.

Yup, you'd need to implement the Bitcoin protocol and load the private key and sign all the messages the echo endpoint receives.

And even then, you couldn't prove the piñata wasn't only proxying the replies from some other server.

The code is open source, so you could
Post reply on HN