public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?
@ 2016-07-30 23:18 Paul Sztorc
  2016-07-31  1:31 ` Bryan Bishop
  2016-07-31  5:18 ` Luke Dashjr
  0 siblings, 2 replies; 3+ messages in thread
From: Paul Sztorc @ 2016-07-30 23:18 UTC (permalink / raw)
  To: Bitcoin Dev

Dear list,

As we know, it would be desirable for Alice, running an SPV client, to tip (say $5) anyone who can prove to her that a given block has invalid content.

If no one takes these tips, then this is weak evidence that the entire block is valid. Alice gets validation, full nodes can get paid...this idea goes back to Satoshi's whitepaper.

In my view, "alerts" are relatively straightforward: a new OP CODE (details below) st. the txn only succeeds if it references invalid block content on a "pretender block".

However, my background reading seems to reveal that "fraud proofs" (as they are now called) require some kind of tremendous engineering overhaul. Can anyone point me to these large problem(s)?

Regards,
Paul Sztorc


------------------------------------

Fraud Proof, Simple (?)


1. "OP FraudProof", which:
	1. Contains arguments [a] block number (from Alice), [b] block header, and [c] merkle path from header to an invalid transaction*.
	2. Checks to see if the provided header _is_ in the position which Alice requested.
	2. Checks to see if the header _is_ valid (ie, has sufficient work).
	3. Checks to see if the merkle path _does_ lead from the header to "something invalid"*.

2. This OP Code can then be used in a transaction of the form:
	Inputs:
		1 from Alice
		0.2 from X**
	Output:
		1.2 to Alice, timelocked
		(or)
		1.2 to X, OP FraudProof .


3. Alice could sign this txn and circulate it, waiting for "X" to add the second signature. 

"Eric", for example, might sign. As soon as Alice get's Eric's signature, she [1] assumes the block *is* invalid, and [2] stops offering to buy FraudProofs on it.

If Eric does not deliver the fraud proof, Alice gets her money back + 0.2 BTC from Eric (for wasting her time). Alice can't lose -- she either buys a fraud proof for 1, or she gets a free 0.2.

Eric can't lose either. Either he doesn't sign (and nothing happens), or he places himself in a position to trade a FraudProof for 1 BTC.

- FraudProof can use "OP Equal" to request fraud for a certain block.
- This can all happen through the lightning network.

* "invalid transaction" is defined either [1] as a script which fails, or [2] a double-spend (headers/paths to 2 txns spending the same input). This definition does not catch bad coinbase transactions, but this doesn't concern me. Those outputs aren't spendable for 100 blocks, and anyway, SPV clients could be programmed to never accept them (it would be annoying, but possible).

** For simplicity, I assume that "FraudProof sellers" will pre-identify themselves (and their unspent outputs, etc, by making them "watching only" or whatever).

---

Now, I wouldn't describe this as a "weekend project", but I wouldn't describe it as an "engineering overhaul" either. Just a new OP Code, and code to create / scan for these "Alert Transactions". So, if the idea is 5+ years old, what's the hold up?

I've also heard that segwit will help, but don't understand why.




^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-07-31  5:18 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-30 23:18 [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ? Paul Sztorc
2016-07-31  1:31 ` Bryan Bishop
2016-07-31  5:18 ` Luke Dashjr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox