[bitcoin-dev] Safety of committing only to transaction outputs

2019-05-24 Thread Johnson Lau via bitcoin-dev
This is a meta-discussion for any approach that allows the witness committing to only transaction outputs, but not inputs. We can already do the following things with the existing bitcoin script system: * commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with optional SIGHASH_ANY

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
Hi Jimmy, The message could really be anything. For example, in discreet log contracts, AFAIU, you might have a specific public key from a trusted third party (the Oracle) that is signs the closing price of corn in BTC on 2019-05-23 with a particular nonce dedicated to that product-date pair, in

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
Hello ZmnSCPxj, I agree that adding OP_CHECKSIGFROMSTACK doesn't preclude adding shortcuts such as `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`, and I agree we ought to support such operations directly, especially if we see widespread use of these constructions in practice. I think it is

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Jimmy, ‐‐‐ Original Message ‐‐‐ On Friday, May 24, 2019 1:36 AM, Jimmy Song via bitcoin-dev wrote: > Hi Russell, > > This is probably a dumb question, but I'd like to get some clarity on your > proposal. > > OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread ZmnSCPxj via bitcoin-dev
> For better or for worse, without an OP_PUBKEYTWEEK operation available, the > more interesting recursive-covenants remain largely out of reach, with the > exception of a recursive covenant that is only able to send back to its own > address, possibly abusing its own TXO value as a state variab

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-24 Thread Johnson Lau via bitcoin-dev
A gamble like this, decentralised or not, is easy to manipulate since difficulty is determined entirely by the last block in a cycle > On 24 May 2019, at 1:42 AM, Tamas Blummer via bitcoin-dev > wrote: > > Difficulty change has profound impact on miner’s production thereby introduce > the big

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-24 Thread Natanael via bitcoin-dev
On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If the difficulty can be directly observed by the script language, you > would need to re-evaluate all scripts in unconfirmed transactions > whenever the difficulty changes. This complic

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
On Wed, May 22, 2019 at 5:01 PM Russell O'Connor wrote: > In concert, these two operations enable: > > * Oracle signature verification, including discrete log contracts. > Jonas informs me that I've misunderstood how discreet log contracts work. The DLC signatures are not directly checked by Scr

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-24 Thread Tamas Blummer via bitcoin-dev
yes, log2work is already computed and would be a strictly increasing value, like time. Thank you for this suggestion. I think attempting an implementation will give further clues it this more suitable to express the same. Tamas Blummer > On May 24, 2019, at 10:36, Natanael wrote: > > On Thu,