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,
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
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
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
> 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
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
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
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
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
