Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?

2016-07-30 Thread Luke Dashjr via bitcoin-dev
On Saturday, July 30, 2016 11:18:36 PM Paul Sztorc via bitcoin-dev wrote: > 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

[bitcoin-dev] BIP114 MAST updated

2016-07-30 Thread Johnson Lau via bitcoin-dev
I have published a new version for BIP114 MAST. It's a bit more complicated with some new features: 1. It allows different parties in a contract not to expose their scripts to each other until redemption. 2. It includes a field to indicate the script language version so new opcodes could be

Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?

2016-07-30 Thread Bryan Bishop via bitcoin-dev
On Sat, Jul 30, 2016 at 6:18 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I've also heard that segwit will help, but don't understand why. > There are some helpful discussions that happened over here:

[bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?

2016-07-30 Thread Paul Sztorc via 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

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

2016-07-30 Thread Leo Wandersleb via bitcoin-dev
gmaxwell just made me aware of this mail thread [0]. Some days ago I had independently and naively started implementing "something similar" [1]. My version totally ignored the commitment and signing part but I'm pretty sure that 12GB is overkill. My code is currently broken and I have no time to