Re: [bitcoindev] Re: Introducing Hourglass

[Saint Wenhao <saintwenhao@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4891 bytes --]

> Relative to other approaches, Hourglass is also the most
incentive-compatible with miners. If P2PK spends are limited to 1 per
block, it is possible we will see potential bidding wars for these
transactions at the fee level-- distributing some of the funds accrued
through quantum retrieval to miners in the form of high fees.

I have some good news: it can be done without any soft-forks, if needed. If
the main goal is to restrict spendability of coins, by relying on Proof of
Work, then it can be done, by using OP_SIZE on DER signatures, and
combining it with OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY, as
proposed by ertil here:
https://bitcointalk.org/index.php?topic=5551080.msg65724436#msg65724436

The simplest Script has this form, and can be used inside P2WSH:

OP_SIZE OP_CHECKSEQUENCEVERIFY OP_DROP <pubkey> OP_CHECKSIG

Then, everything is timelocked to at least 9 blocks, if secp256k1 and
SHA-256 is fully broken, but it depends mainly on the size of the
signature, and more realistic sizes are something around 70 bytes (or
around 60 bytes, if someone wants to use half of the generator as R-value;
some miners can do that, if they can be sure, that nobody will reorg their
blocks, and if they are not worried about revealing their keys for some
addresses). The granularity can be increased, for example by a factor of
four, like it was in Signet faucet:
https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937

OP_SIZE OP_DUP OP_ADD OP_DUP OP_ADD OP_CHECKSEQUENCEVERIFY OP_DROP <pubkey>
OP_CHECKSIG

Then, realistically, things can be timelocked to something like 70*4=280
blocks, and users can decrease it by four blocks for each grinded byte in a
given signature. If private key for every secp256k1 point is known, the
size of the signature will decrease to something like 40 bytes, so things
will be still timelocked to something around 160 blocks, and will still
require SHA-256 grinding, to move coins faster.

niedz., 4 maj 2025 o 11:12 Hunter Beast <hunter@surmount.systems>
napisał(a):

> Trading volume is a good perspective to view this through, actually. If an
> attacker decides to consolidate immediately, they could do so within just a
> couple hours and suppress the Bitcoin price for a long time.
>
> > 1.7 million Bitcoin represents possibly about 1 week of global trading
> volumes. Even assuming it is 1-2 months of trading volumes, the market can
> absorb.
>
> Hourglass spreads that 1 week of trading volume over a minimum of 8
> months, possibly more.
>
> > Trying to manage the Bitcoin price via spending restrictions is a
> terrible idea.
>
> While I generally agree with this sentence, I think P2PK coins are an
> exceptional case.
>
> > In any case, the Bitcoin price routinely drops by upwards of 85%. It is
> not a security concern. Price volatility is not a security.
>
> Price volatility absolutely impacts security, and this would be an
> unprecedented event. We also haven't seen an 85% price drop in a long time.
>
> On Saturday, May 3, 2025 at 5:55:28 AM UTC-6 Francis Pouliot wrote:
>
>>
>> Concept NACK.
>>
>> 1.7 million Bitcoin represents possibly about 1 week of global trading
>> volumes. Even assuming it is 1-2 months of trading volumes, the market can
>> absorb.
>>
>> Trying to manage the Bitcoin price via spending restrictions is a
>> terrible idea.
>>
>> In any case, the Bitcoin price routinely drops by upwards of 85%. It is
>> not a security concern. Price volatility is not a security.
>> On Tuesday, April 29, 2025 at 5:08:16 PM UTC-6 Hunter Beast wrote:
>>
>>> This is a proposal to mitigate against potential mass liquidation of
>>> P2PK funds. The specification is pretty simple, but the motivation and
>>> justification for it is a bit longer.
>>>
>>>
>>> https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki
>>>
>>> Feedback welcome!
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4f35a82a-bedb-4d4d-9de2-2dbc340b18acn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/4f35a82a-bedb-4d4d-9de2-2dbc340b18acn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOJxNHQfTQdzz8uzd0S9erwF27ND0ASMWxxUqGBkKy%2BVVg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6425 bytes --]