lavalamp

Karma: 2,094

lavalamp Jan 6, 2014, 6:39 AM
0 points
in reply to: Mark_Friedenbach’s comment on: A proposed inefficiency in the Bitcoin markets

Perhaps this isn’t obvious, but note that fully validating nodes do not need to store the entire block chain history, currently, just the set of unspent transaction outputs, and there are proposals to eliminate the need for validators to store even that. If it’s just a gentleman’s agreement then it would be doable but wouldn’t really have any teeth against a motivated attacker.

That’s a good point. To make this work, it’d probably make the most sense to treat the pre-published hash the same as unspent outputs. It can’t be free to make these or you could indeed DoS bitcoin.

I did not know you could have zero value outputs. I’ll look into that. (And don’t worry, I wasn’t planning on destroying any coins!)

lavalamp Jan 3, 2014, 9:38 PM
0 points
in reply to: Mark_Friedenbach’s comment on: A proposed inefficiency in the Bitcoin markets
Infinitely is a bit of an overstatement, especially if there’s a fee to store a hash. I agree it might still be prudent to have a time limit, though. Miners can forget the hash once it’s been referenced by a transaction.

The ability to pay to store a hash in the blockchain could be interesting for other reasons, like proving knowledge at a particular point in the past. There’s some hacky ways to do it now that involve sending tiny amounts of BTC to a number of addresses, or I suppose you could also hash your data as if it were a pubkey and send 1e-8 btc to that hash—but that’s destructive.

lavalamp Jan 3, 2014, 2:25 AM
0 points
in reply to: Mark_Friedenbach’s comment on: A proposed inefficiency in the Bitcoin markets
Thanks for the explanation, it seems like I’m not wildly misreading wikipedia. :)

It seems like the more qubits are required for this attack, the more likely we are to have a long warning time to prepare ourselves. The other attack of just cracking the pubkey when a transaction comes through and trying to beat the transaction, seems vastly more likely to be an actual problem.

Do you have any idea how I’d go about estimating the number of qubits required to implement just the SHA256(SHA256(...)) steps required by mining?

lavalamp Jan 3, 2014, 2:17 AM
0 points
in reply to: Mark_Friedenbach’s comment on: A proposed inefficiency in the Bitcoin markets
They don’t.

Suppose you publish hash HT1 of a transaction T1 spending address A, and then several blocks later when you publish T1 itself, someone hacks your pubkey and publishes transaction T2 also spending address A. Miners would hypothetically prefer T1 to T2, because there’s proof that T1 was made earlier.

In the case where someone had even earlier published hash HT0 of transaction T0 also spending address A, but never bothers to publish T0 (perhaps because their steal bot—which was watching for spends from A—crashed), well, they’re out of luck, because A no longer has funds as soon as T1 is included in the blockchain.

The pre-published hashes would be used only to break ties among transactions not yet included in any blocks.

Also, in this hypothetical scenario, the steal-bot from above means you shouldn’t trust funds that haven’t yet been moved into a quantum-computer-safe address; you wouldn’t know who all might have a old hash published with a bot just waiting to spend your funds as soon as you try to move them.

lavalamp Jan 2, 2014, 7:55 AM
0 points
in reply to: Mark_Friedenbach’s comment on: A proposed inefficiency in the Bitcoin markets
I always forget about the RIPEMD-160 step. The bitcoin wiki claims that it’s strictly more profitable to mine than to search for collisions, but it seems to me that that’s a function of block reward vs. value of address you’re trying to hack, so I don’t know if I believe that. https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

It’s unclear to me how you would actually implement this in a quantum computer; do you have to essentially build a set of quantum gates that implement RIPEMD-160(SHA256(pubkey))? Does this imply you need enough qubits to hold all stages of the calculation in memory at the same time? I haven’t been able to figure out from wikipedia how I’d arrange qubits to do a single hashing operation. Given that it’s a lot of sequential steps, perhaps it actually takes a lot of qubits chained together?

lavalamp Jan 2, 2014, 7:24 AM
0 points
in reply to: Mark_Friedenbach’s comment on: A proposed inefficiency in the Bitcoin markets
I think you misunderstood me—the transaction could still be rejected when you try to get it included in a subsequent block if it’s not valid. The hash of the transaction is just to prove that the transaction is the first spend from the given address; the transaction doesn’t/can’t get checked when the hash is included in the blockchain. Miners wouldn’t be able to do it for free—the protocol addition would be that you pay (from a quantum-safe address) to include a hash of a transaction into the blockchain. You publish the actual transaction some number of blocks later.

It really only makes sense as an emergency “get your coins into an address that’s quantum computer proof” sort of addition. Hopefully the problem is solved and everyone moves their funds before it becomes an emergency.

lavalamp Jan 1, 2014, 7:08 AM
2 points
in reply to: Adele_L’s comment on: Welcome to Less Wrong! (5th thread, March 2013)
Me three—I thought I was the only one, where are we all hiding? :)

lavalamp Dec 31, 2013, 11:35 PM
2 points
in reply to: Douglas_Knight’s comment on: A proposed inefficiency in the Bitcoin markets
That’s true, but there’s some precedent for picking a block that everyone agrees upon (that exists before quantum computers) and changing the rules at that block to prevent someone from rewriting the blockchain. A lot depends on how much warning we have.

It looks like making a cryptocoin that can survive quantum computers might be a high value activity.

lavalamp Dec 31, 2013, 12:52 AM
2 points
in reply to: Douglas_Knight’s comment on: A proposed inefficiency in the Bitcoin markets

I think a gigahertz quantum computer would have the hashing power of the current bitcoin network.

My math agrees with you. Looks like I was underestimating the effect of quantum computers.

Difficulty is currently growing at 30-40% per month. That won’t last forever, obviously, but we can expect it to keep going up for a while, at least. (https://blockchain.info/charts/hash-rate) Still, it looks like you’d need an unrealistic amount of ASICs to match the output of just 1000 quantum computers.

Given that, there’ll probably be a large financial incentive to mine bitcoins with the first quantum computers. The incentive goes away if you destroy the network in the process, though. It seems difficult to predict what will happen. Single pools have controlled > 50% of the mining briefly in the past.

...given such a disruption, I don’t see much point to salvaging the old currency, rather than starting over.

A lot of unhappy btc holders may see a point, though. :)

lavalamp Dec 31, 2013, 12:08 AM
4 points
in reply to: ChristianKl’s comment on: A proposed inefficiency in the Bitcoin markets

This is not completely true—since only hashes of the public key are posted until funds are spent from an address

So what? Then the attacker waits till someone spents his funds and double spends them and gives the double spending transaction a high processing fee.

This can be fixed by a protocol addition, which can be implemented as long as there’s warning. (First publish a hash of your transaction. Once that’s been included in a block, publish the transaction. Namecoin already does something like this to prevent that exact attack.)

lavalamp Dec 27, 2013, 9:34 PM
2 points
in reply to: ChristianKl’s comment on: A proposed inefficiency in the Bitcoin markets

Bitcoins has such risks as a mathematician inventing a way to break public key crypto that would completely destroy it. Again if people build useable quantum computers, bitcoin is gone.

This is not completely true—since only hashes of the public key are posted until funds are spent from an address, you need both (a quantum computer or a public key crypto break) and a major break in SHA256. If only one thing breaks, there may be enough time for bitcoin devs to make a fix. It’d be relatively easy to switch to a different address hashing algo, and the whole internet is going to hurt badly if public key crypto can’t be fixed when quantum computers become common, so there’s a lot of motivation to find a replacement.

(It’s hard to imagine a break in SHA256 that’s complete enough to affect mining—weakenings are just the equivilent of running extra hardware.)

(It’s also not completely false, as I still expect events like that to still cause a large temporary depression in bitcoin price.)

lavalamp Nov 22, 2013, 7:48 PM
38 points
on: 2013 Less Wrong Census/Survey
Thanks for running these, I took it. :) Love the prize question.

...I’m way off on the population of Europe, as I expected.

lavalamp Nov 20, 2013, 11:32 PM
7 points
on: Please vote for a title for an upcoming book
I’m not a fan of any of the options.

lavalamp Oct 28, 2013, 8:16 PM
0 points
in reply to: Nectanebo’s comment on: Less Wrong’s political bias
I’m not sure how to measure it, either—hence my pledge of karma for whoever figures it out. :)

lavalamp Oct 25, 2013, 8:51 PM
10 points
on: Less Wrong’s political bias
I would upvote an attempt to actually measure LW’s political bias.

lavalamp Oct 24, 2013, 7:30 PM
2 points
in reply to: Viliam_Bur’s comment on: What Can We Learn About Human Psychology from Christian Apologetics?
Yeah, good point, agreed—I’m possibly in the former category there, it’s hard to say.

lavalamp Oct 23, 2013, 11:50 PM
11 points
in reply to: ChrisHallquist’s comment on: What Can We Learn About Human Psychology from Christian Apologetics?

I’d actually be surprised if LessWrong made many deconverts

raises hand

One could argue that LW just made the inevitable happen faster, though.

lavalamp Oct 10, 2013, 10:41 PM
11 points
in reply to: ChrisHallquist’s comment on: A Voting Puzzle, Some Political Science, and a Nerd Failure Mode
Not at all! Go for it!

lavalamp Oct 10, 2013, 12:13 AM
59 points
on: A Voting Puzzle, Some Political Science, and a Nerd Failure Mode
Needs a TL;DR:
1. Politicians probably conform to the median voter’s views.
2. Most voters are not the median, so most people usually dislike the winning politicians.
3. But people dislike the politicians for different reasons.
4. Nerds should avoid giving advice that boils down to “behave optimally”. Instead, analyze the reasons for the current failure to behave optimally and give more targeted advice.
What links here?
- A Voting Puzzle, Some Political Science, and a Nerd Failure Mode by ChrisHallquist (Oct 10, 2013, 2:10 AM; 142 points)

lavalamp Oct 8, 2013, 11:56 PM
6 points
in reply to: Eliezer Yudkowsky’s comment on: Open Thread, October 7 - October 12, 2013
Do you have any evidence that the cause is not ordinary aging?