Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and
OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for
Bitcoin via new Script operations. However, I think that these proposals
miss the mark when it comes to how they approach Bitcoin Script and
language
On Wed, May 22, 2019 at 06:04:27AM +, ZmnSCPxj via bitcoin-dev wrote:
> * I do not think CoinJoin is much improved by this opcode.
I think (especially with cross-input sig aggregation) it makes it easier
to do a coinjoin during a high fee period -- if you're willing to wait
'til fees are
On Wed, May 22, 2019 at 10:06 PM Pieter Wuille
wrote:
> On Tue, 21 May 2019 at 10:20, Russell O'Connor
> wrote:
> >
> > Regarding Tapscript, the specification calls for the final value of the
> stack being a single non-false value:
> >
> >> The tapscript is executed according to the rules in
Good morning Jeremy,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, May 22, 2019 4:10 PM, Jeremy wrote:
> > * I do not think CoinJoin is much improved by this opcode.
> > Typically, you would sign off only if one of the outputs of the CoinJoin
> >
On Wed, May 22, 2019 at 12:17:31PM +0930, Rusty Russell wrote:
>I prefer to
>change the bip introduction to expliclty shout "THESE SIGNATURE
>HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it
>SIGHASH_UNSAFE_ANYPREVOUT.
> 4. "Rebinding is a new power in bitcoin, and
On Tue, 21 May 2019 at 10:20, Russell O'Connor wrote:
>
> Regarding Tapscript, the specification calls for the final value of the stack
> being a single non-false value:
>
>> The tapscript is executed according to the rules in the following section,
>> with the initial stack as input
>> II.
Good morning Russell,
While I am sympathetic to this argument from first principles, as I understand
it, it requires that provided witness inputs will become larger, compared to
"shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`.
For instance, to simulate
The complains I could imagine about this, (apart from being a very
specific use case) are the same complains I heard about op_expiry.
Namely, that in a reorg, the same tx, having been valid in a given
block could potentially become invalid in some other block mining it.
I guess in this case the
You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
See
It's true that it fetches the block hash; the idea is to compare the block
hash's numeric value to the desired (uncompressed) difficulty directly,
using a 256-bit version of OP_LESSTHAN.
Nathan Cook
On Thu, 23 May 2019 at 22:18, Tamas Blummer wrote:
> That opcode would not help as it fetches
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 pubkey.
Presumably, the message would then have to get constructed as part of the
Script execution. What would such a message look
Difficulty change has profound impact on miner’s production thereby introduce
the biggest risk while considering an investment.
Commodity markets offer futures and options to hedge risks on traditional
trading venues. Some might soon list difficulty futures.
I think we could do much better than
That opcode would not help as it fetches block hash and not the content of the
header.
> On May 23, 2019, at 21:05, Nathan Cook wrote:
>
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
>
The parameter used is property of the block just like the block height is a
property and is already evaluated in scripts,
so no new kind of dependency or encapsulation break.
The transaction itself was not invalid in a re-org but evtl. others spending it
if the difficulty on that fork is
> On May 23, 2019, at 21:45, Pieter Wuille wrote:
>
> On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
> wrote:
>>
>> Difficulty change has profound impact on miner’s production thereby
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer
On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
wrote:
>
> Difficulty change has profound impact on miner’s production thereby introduce
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional
> trading venues.
I see. The uncompressing needs to be done either to compare. How are chances
for that BIP?
This BIP would be explicitly offering risk managment of miners biggest risk.
Doing so without relying on external markets or oracle, self cointained would
be an impressive and adequate feature.
Tamas
Block hash can suggest much higher difficulty than what is in effect, so
OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the level
of the bet.
> On May 23, 2019, at 21:45, Tamas Blummer wrote:
>
> I see. The uncompressing needs to be done either to compare. How are
You're right, I didn't remember the whole procedure. You provide the
80-byte header in the spend script, duplicate it on the stack, hash it, and
compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on
the header with OP_AND to extract the difficulty. You can compare two
19 matches
Mail list logo
