Dear Gregory,
First of all, I would like to express my deep appreciation to your entire
craft in the FOSS ecosystem, specially in Bitcoin, even more In Blockstream.
I think you are a brilliant engineer and very principled leader. your
efforts are an inspiration for many, a truly enduring forever m
Hello all,
I started writing code that puts the signature in the coinbase
transaction similar to the witness commitment, and encountered a
potential issue. See inline comments below.
On Mon, Mar 11, 2019 at 2:02 AM David A. Harding wrote:
>
> On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan
Good morning Alistair,
> It won't have escaped notice that the HTLB script can be wholly written
> in an
> HTLC script: 'HTLB over HTLC', however there are additional reasons to
> consider HTLB for a separate BIP:
I believe there is indeed an important usecase for HTLB over HTLC, whi
I think you may have misunderstood part of the motivation. Yes, part of the
motivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the
theoretical operation of checksig operations (thus somewhat simplifying the
implementation but also simplifying analysis of future changes, su
Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size
limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few
more (overhead for varints) = 572ish bytes should be enough to completely
eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH
transactions wi
Hi Jacob,
> Huh?! The whole point of non-standardness in this context is to (a) make
>>> soft-forking something out safer by derisking miners not upgrading right
>>> away and (b) signal something that may be a candidate for soft-forking
>>> out so that we get feedback. Who is getting things disab
Greetings all,
I'm looking for thoughts on the BIPability of a relatively minor change, with
an outsize benefit, with the provisional name 'Hashed Time-Locked Bond', HTLB
for short.
The minor change is to implement HTLC without its digest element. The outsize
benefit is to incentivise against
What about putting it in a deprecated state for some time. Adjust the
transaction weight so using the op code is more expensive (10x, 20x?) and
get the word out that it will be removed in the future.
You could even have nodes send a reject code with the message
“OP_CODESEPARATOR is depcrecated.”
>Lock in a blockheight to get rid of it 10 years in the future.
And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to
the soft fork activation standard, with weight penalties as appropriate, so
there would be no difficulty spending them before the cutoff?
On Sun, Mar 10, 2019
On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> Keeping the PoW rule and moving the signature would mean DoS attacks
> would be trivial as anyone could mine blocks without a signature in
> them
Sure, but anyone could also just connect their lite client to a truste
I fear that we cannot simply wait 10 years to address the vulnerability
that OP_CODESEPARATOR has in its current form.
On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH <
willt...@live.com.au> wrote:
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as
11 matches
Mail list logo
