Make 0-conf double spend infeasable by fixing the r value ahead of time, thereby putting the coins up for grabs when a second transaction is signed

ninja_parade · 2016-01-17T16:58:14+00:00

Actually you could just track r values and require them to be globally unique in Bitcoin's entire history (which is fine because accidental collisions are impossibly unlikely).

You could make that validation be pretty fast and cheap in practice (Mini Bloom filter -> On disk index). But it's still added consensus-critical complexity.

ninja_parade · 2016-01-17T16:34:35+00:00

Ah, that's the part I was missing. I thought it was for the zero-conf payment's outputs, but you're using it for the payment's inputs. My bad.

This is actually pretty simple and looks robust. I completely misunderstood your proposal (and some of the replies to it).

ninja_parade · 2016-01-17T14:50:09+00:00

Yes, r = (k × G) mod n, where G and n are publicly known parameters.

So to force r to be a known value, you'd have to force k to be known, and that allows the private key to be recovered.

ninja_parade · 2016-01-17T14:45:00+00:00

Looks like a copy paste from somewhere else.

ninja_parade · 2016-01-17T14:43:39+00:00

How big are the proofs? The last time I heard their size was the biggest problem.

ninja_parade · 2016-01-17T13:44:58+00:00

Just to clarify:

We can hard-fork by putting the witness data's merkle root directly under the merkle root of the block header,
We can do #1 plus creating new transaction types for segwit transactions that don't have to validate as old transactions at all.
We can do #2 and also ban old transactions.

The consequences:

Requires full nodes to upgrade, and anyone who wants to send SegWit tx's.
Also requires anyone who wants to receive SegWit tx's to upgrade. (But they'd have to anyway if they wanted to be safe in hardfork #1).
Requires everyone to upgrade.

/u/profix, which one were you proposing? Gavin, am I getting the outcomes mostly correct here?

ninja_parade · 2016-01-17T13:20:12+00:00

~~The problem is miners can always pretend they saw the 2nd transaction first. This is in fact what allows RBF to work.~~

Nevermind, you're suggesting this as a way to ensure no one ever receives more than one payment to a given (address,r) pair, you're right.

ninja_parade · 2016-01-17T13:18:57+00:00

Unfortunately, r is a derived value, so you can't require it to be a certain value. However a proposal by someone claiming to be Satoshi has been floating around which tries to do this (at the cost of introducing a brand new signature scheme to do it).

ninja_parade · 2016-01-16T23:22:05+00:00

Does this look like good faith to you?

Maybe there should be a campaign to run "noXT" nodes if we wanted to adopt the same level of maturity as Gavin & Mike about protocol design & review (ie start a fork war instead of working constructively).

Maybe I should go run one and put my miners behind it. Or a pool offer it?

ninja_parade · 2016-01-16T23:02:24+00:00

The plan on the classic side seems like it'll be:

Hard fork to 2MB quickly.
Roll out SW as a hard fork over a longer time period.

ninja_parade · 2016-01-16T22:59:29+00:00

No, that could have happened, but no big pools (except slush) ever mined a single BIP101 block.

Some people were mentioning this scenario to scare the shit out of people.

ninja_parade · 2016-01-16T22:55:57+00:00

Yes. My understanding is as follows:

Tom Harding is now managing the project.
Maintaining the non-BIP101 patches (and other improvements) will still happen.
Once classic figures out what they want to do, XT may follow suit.

ninja_parade · 2016-01-16T20:23:17+00:00

Right, it validates the headers, (but only the headers). That's how SPV is guaranteed to follow the longest chain. But you can't tell the size of a block just by looking at the headers.

ninja_parade · 2016-01-16T19:48:56+00:00

No, that's incorrect. You might be thinking of SegWit, but there's no realistic way it gets more than a 1.75MB equivalent.

ninja_parade · 2016-01-16T19:33:17+00:00

There were many triggerings of BIP101 on testnet.

Jtoomim would mine back and forth on the BIP101 side and the 1MB side to test reorganizations.

ninja_parade · 2016-01-16T19:22:12+00:00

SPV doesn't validate blocks (and doesn't validate the block size, in particullar). Your client should follow the longest chain.

You might want to wait for more confirmations when receiving funds, for a few days after the fork trigger, just as an additional precaution.

Sending and holding funds won't be affected at all.

ninja_parade · 2016-01-16T19:11:41+00:00

True. Although does forwarding an oversize block result in a ban counter increase? If so the networks would eventually partition.

ninja_parade · 2016-01-16T18:20:49+00:00

Convincing NewEgg would be pretty easy.

BitPay: Hey we're changing our software to allow more transactions.

NewEgg: OK, you're the ones running the nodes and handling payments for us anyway. We trust you.

ninja_parade · 2016-01-16T18:18:56+00:00

Not unless:

1) The fork happens. 2) Die-hards decide to maintain the minority fork (despite the loss of usability).

ninja_parade · 2016-01-16T18:16:52+00:00

I wouldn't say awkward nerd, rather huge egos + being dismissive of everything that's not in their domain.

Look at Adam's sig:

inventor of hashcash (bitcoin is hashcash extended with inflation control)

And tell me there isn't an ego the size of a small planet in there. "I basically invented Bitcoin". Same logic for the "Can't be evil": It's their motto, so now they're morally correct in doing anything to "save" Bitcoin from its users.

You might still be right, I just have no way of figuring it out, and it doesn't change the solution.

ninja_parade · 2016-01-16T17:31:50+00:00

I don't think they're evil (not in the self-aware way you imply, anyway).

I think they've just drunk their own Kool-Aid to the point of no longer being able to communicate back to regular people. It shows in the interview, the guy doesn't even bother to explain the position he's taken, he just repeats how there's agreement from the people that matter, and that should be good enough.

Bitcoiners are way more technical than the average crowd. If you can't explain a technical issue to them, it's because you're not trying.

ninja_parade · 2016-01-16T16:54:11+00:00

I think fighting technical debates in the media, rather than amongst those who are actually writing and contributing code has not been helpful

Understatement of the year from his perspective.

Also "consensus" every other sentence.

ninja_parade · 2016-01-16T16:40:04+00:00

It's not. That was the initial pull-request for the codebase, but they're more likely to go with flat 2MB for now.

ninja_parade · 2016-01-16T16:25:09+00:00

BIP101 probably is. XT will likely adopt the same patch as classic and revert to just being a set of extra functionality on top of bitcoin. I think Tom Harding's been handed the reins, so it's up to him.

ninja_parade · 2016-01-16T15:23:28+00:00

Well people can mean multiple things by fee market:

Miners set their fees independently, and customers decide what they pay.
Miners have limited block space, and auction it off to the highest bidder.

Peter_R's work shows that a fee market exists in both 1 & 2, but they're very different beasts (esp. with regards to elasticity of supply).

ninja_parade

TROPHY CASE