Nostr notes by Billy Tetrud [ARCHIVE]

📅 Original date posted:2023-01-23 🗒️ Summary of this ...

2023-06-07T23:18:41Z

In reply to nevent1q…k7ts
_________________________

📅 Original date posted:2023-01-23
🗒️ Summary of this message: A simple way to create a wallet vault without requiring key deletion is to create an N-of-N multisig address and pre-sign transactions from it with N-1 keys.
📝 Original message:In the discussion around James' OP_VAULT proposal, it was implied that
precomputed vaults must use ephemeral keys that must be deleted as part of
the vaulting protocol, like Bryan Bishop's proposal
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html>;.
Looking around, I haven't been able to find any wallet vault proposal that
doesn't require ephemeral keys, so at the risk of posting something that's
obvious to everyone, I wanted to share a simple way to do a wallet vault
without requiring any key deletion.

The basic idea is to create an N-of-N multisig address, and pre-sign some
transactions from it with N-1 keys to an address with several timelocked
spend paths. This has the fallback that funds can always be spent
immediately if you use all the keys, just like a normal N-of-N multisig
address (since that's what it is at its core), but the usage of any of the
pre-signed transactions leads to an address that guarantees a clawback
within a time window. Here's a 3-of-3 example:

*Vault Initialization*:
1. Create 3 of 3 Vault Address
2. Create an Interim Address that can send with:
* 1 of 3 keys after a timelock of 1 month
* 2 of 3 keys after a timelock of 1 week
* 3 of 3 keys with no timelock

*Vaulting*:
1. Create a transaction sending an output to the Vault Address
2. Create a transaction spending that Vault Address output to the Interim
Address
3. Presign one copy of the step-2 transaction for each of the three
combinations of two keys.
4. Store seeds separately, store the wallet config as well as the three
presigned transactions with each seed.

*Unvaulting*:
1. Sign one of the pre-signed transactions with the missing signature.
2. Broadcast
3. Wait the appropriate timelock for the number of keys you want to sign
with.
4. Create a transaction sending from the Interim Address.
5. Broadcast

*Recovering *(after unvaulting step 2 after the broadcasted transaction to
the Interim Address has been mined):
1. Sign the utxo with all three keys to any destination. Alternatively sign
with two keys, wait 1 week.
2. Broadcast it

This has the usual downsides of pre-signed vaults that you need to backup
these transactions for each vaulting, complications involving the
flexibility (or lack thereof) of fees, and inflexibility in how much to
unvault (must be the whole utxo, no change). This could of course be
augmented with various techniques to make fee handling more flexible
(anchor outputs, multiple versions of the presigned transactions with
different fees, etc). More complicated presigning schemes could allow for
some flexibility in unvaulting amount (eg by sending change back into the
vault, and creating additional pre-signed transactions for that new output).

It also has the same downside that OP_CTV vaults have, where a stolen key
can steal funds from the interim address by racing the owner with their own
transaction once the necessary delay has passed. Note that James' OP_VAULT
opcode wouldn't have this problem.

But not requiring any toxic waste keys seems like a pretty good benefit
over Bryan Bishop's original proposal.

Anyways sorry if this was already on people's radar and just too obvious to
post about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230123/eb519e3d/attachment.html>;

📅 Original date posted:2022-05-01 📝 Original message:> ...

2023-06-07T23:08:53Z

In reply to nevent1q…sqar
_________________________

📅 Original date posted:2022-05-01
📝 Original message:> If a QC is able overnight to spend a large fraction of the supply, your
coins in your super non-QC vulnerable-bare-CTV-covenant (that would
eventually become vulnerable when trying to use it) are worthless.[1]

I know this has been debated to death, but I really don't think this
argument is very convincing. First of all, why are we assuming that if for
example, "satoshi's hoard" of 5+ million bitcoins was stolen, that it would
mean bitcoin becomes worthless? To me this is an absurd assumption to make.
The thief almost certainly wouldn't want to just destroy bitcoin. But even
if they did and put it all up for sale overnight, yes it would tank
bitcoin's price *temporarily*. But in the long run, this is less than 1/3
of the supply, and it at worst could be considered monetary inflation of <
30%, and so that's the amount that the price should take a hit of: less
than 30%. Plenty of fiat currencies have survived worse.

Second of all, its incredibly unlikely that someone is suddenly going to be
able to do QC so well that they jump straight to being able to find "a
large fraction" of the private keys out there, or enough private keys to
make up a large fraction of the supply. Its far more likely that the first
quantum computers that are able to derive *any* private keys will still
take a long time (weeks? months?) to do one. If you have your bitcoins in a
segwit address, you know that they can't be stolen by a quantum computer.
You can sit back calmly, and figure out what to do next. By contrast, if
your life savings is in a taproot address, you have to drop everything with
your underwear on fire and recklessly move that stuff ASAP. Chances for
hasty mistakes is high.

But lets say someone *does* jump to being able to derive 1 private key per
minute (pretty darn fast if you ask me). It would currently take such a
machine 152 years to crack all the 80 million UTXOs in existence. By the
time there are practical quantum machines, it'll probably be at least
double that many UTXOs. If it was trying to crack revealed private keys
from mempool transactions, it could only really hit 10 out of 2000
transactions. Hashing the public key is I think is quite an effective
protection to a quantum computing attack in the vast majority of likely QC
emergence scenarios. I honestly don't understand how someone could come to
a different conclusion.

It makes a lot of sense in a world where quantum computers are now a very
real thing, to store large amounts of bitcoin in a possibly slightly less
efficient way in order to ensure that those funds can't be snatched in a QC
disaster scenario. I would be very interested to see a proposal to add the
option of having a taproot address type that doesn't expose the bare public
key.

On Fri, Apr 29, 2022 at 6:53 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Correction: thinking about this some more, you can't actually expect to
> have a stable txid if you allow additional inputs at all...
>
> So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
> commits to the number of inputs) as proposed in the OP should be sufficient
> to get stable txids for single-input transactions.
>
> (I initially thought that APO has to cover some additional tx parts for
> this, but it seems that it's really just the scriptSig which is guarrnated
> to be empty if you have a single input that is known to be the taproot APO
> spend.)
>
> So in overall, my (1) and (5) points are only applicable to
> APO-as-currently-spec'd and not to the suggested APO revision.
>
> On Fri, Apr 29, 2022 at 1:21 PM Nadav Ivgi <nadav at shesek.info> wrote:
>
>> > This is *literally* what the post you are replying to is proposing to
>> solve.
>>
>> I thought the changes mentioned in the OP (+ committing to the spent
>> input index) only solves the half-spend problem, but not the stable txids
>> one?
>>
>> There can be other inputs with a scriptSig, which doesn't get committed
>> to in the APO hash. I guess this isn't too common, but there might be some
>> cases where you would want to spend some (pre-selected) non-segwit inputs
>> alongside your covenant, maybe for fees. With CTV you would pre-commit to
>> the scriptSig which makes it non-malleable even if the script itself is.
>>
>> > Hmm? You can't have channel factories without Eltoo. (Well, you can in
>> theory but good luck.)
>> > Maybe you are refering to non-interactive channel creation?
>>
>> I was referring to what BIP 119 calls 'Batched Channel Creation' [0],
>> which is a sort of a channel factory construction under a broader
>> definition (and in fact was previously called that in the BIP [1]).
>>
>> > The case for stable txids is less strong if we have APO (and therefore
>> Eltoo).
>>
>> There's merit in using these factory constructs for Poon-Dryja channels
>> even if Eltoo was available.
>> I don't foresee Eltoo taking over the penalty approach entirely, but
>> rather the two living side by side.
>>
>> (It could theoretically be possible to use APO to open Poon-Dryja
>> channels on top of unstable funding txids, but having stable txids makes
>> this much more easily integratable with existing lightning implementations,
>> without the invasive changes that unstable txids would bring.)
>>
>> > This has been addressed over and over and over again. If a QC is able
>> overnight to spend a large fraction of
>> > the supply, your coins in your super
>> non-QC-vulnerable-bare-CTV-covenant (that would eventually become
>> > vulnerable when trying to use it) are worthless.
>>
>> It might be the case that a sufficient fraction of supply does switch
>> over to QC-protected outputs in time, with only some small minority that
>> didn't actively switch over *and* with revealed bare pubkeys losing
>> their funds, which wouldn't make BTC entirely worthless. It makes sense not
>> to want to be in that minority, ideally without requiring further
>> time-sensitive active action (esp if considering long-term deep cold
>> storage for inheritance etc).
>>
>> (This of course assumes a safe post-QC mechanism to later spend these
>> funds; IIUC there are some viable approaches for that using a two-step
>> spending procedure, where you prove knowledge of the pubkey/script preimage
>> while commiting to a future tx.)
>>
>> > Sorry for being sarcastic, but at this point it's not fair to use
>> quantum-computer FUD to justify the
>> > activation of CTV over APO, or encourage the use of legacy transactions
>> over Taproot ones.
>>
>> Sorry if it came off as FUDing. I don't know enough to hold a strong
>> opinion on whether the fear of QCs is justified or not. I know that many
>> people on this list don't think so, but I also think that this fear is
>> prevalent enough to warrant taking it into consideration (at least for
>> features that target long-term SoV use cases; less so for features
>> targeted at L2 MoE applications like lightning spacechains paypools etc).
>>
>> > you can also use the internal key optimization .. you can't have
>> NUMS-ness then
>>
>> Right, which makes this unsuitable for the vaulting use case.
>>
>> > Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>> witness units* (8.25 vbytes).
>>
>> Ugh yes sorry about that! I realized after hitting send and meant to
>> clarify that it should've been s/vbyte/WU/ in my next reply.
>>
>> > Are APO signatures more expensive to verify? .. the cost for the
>> network of validating signatures already exists today
>>
>> Not compared to existing signature verifications, but compared to a
>> CTV/TXHASH-like construction.
>>
>> Can anyone quantify how much of a difference this makes in practice?
>>
>> > i appreciate your reply and your efforts to explore the tradeoffs
>> between the two approaches.
>>
>> Thank you, I appreciate your efforts on this too :-)
>>
>> shesek
>>
>> [0]
>> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
>> [1] https://github.com/bitcoin/bips/pull/1273
>>
>> On Fri, Apr 29, 2022 at 11:31 AM darosior <darosior at protonmail.com>
>> wrote:
>>
>>> Hi Shesek,
>>>
>>> 1. The resulting txids are not stable.
>>>
>>>
>>> This is *literally* what the post you are replying to is proposing to
>>> solve.
>>>
>>>
>>> This property could be important for some of the proposed CTV use-cases,
>>> like channel factories.
>>>
>>>
>>> Hmm? You can't have channel factories without Eltoo. (Well, you can in
>>> theory but good luck.)
>>> Maybe you are refering to non-interactive channel creation? The case for
>>> stable txids is less strong if we
>>> have APO (and therefore Eltoo). [0]
>>>
>>>
>>> 2. APO will only be available on Taproot, which some people might prefer
>>> to avoid for long-term multi-decade vault storage due to QC concerns. (also
>>> see my previous post on this thread [0])
>>>
>>>
>>> This has been addressed over and over and over again. If a QC is able
>>> overnight to spend a large fraction of
>>> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
>>> (that would eventually become
>>> vulnerable when trying to use it) are worthless.[1]
>>>
>>> Sorry for being sarcastic, but at this point it's not fair to use
>>> quantum-computer FUD to justify the
>>> activation of CTV over APO, or encourage the use of legacy transactions
>>> over Taproot ones.
>>>
>>>
>>> 3. Higher witness satisfaction cost of roughly 3x vbytes vs
>>> CTV-in-Taproot (plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of
>>> a single CTV branch*, for the taproot control block. with more branches
>>> CTV-in-taproot eventually becomes preferable).
>>>
>>>
>>> Again, this is what my post discusses. Here are the arguments from my
>>> post about why i don't think it's a big deal:
>>>
>>> 1. You can in this case see CTV as an optimization of (tweaked)
>>> APOAS. A lot of us are doubtful about CTV
>>> usecases for real people. So much that it was even proposed to
>>> temporarily activate it to see if it would
>>> ever have any real traction! [2]
>>> My point with this post was: what if we do (a slightly tweaked)
>>> BIP118, that is otherwise useful. And
>>> if this use of covenants is really getting traction then we can
>>> roll out an optimization in the form of
>>> CTV (or better covenants, as we'd have had more research put into
>>> it by this time).
>>> 2. CTV is mainly sold for its usage inside vaults. While i'm not
>>> convinced, a few more vbytes should not
>>> matter for this usecase.
>>>
>>> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>>> witness units* (8.25 vbytes).
>>> Aside, you can also use the internal key optimization with APO. But i
>>> don't think it's desirable just to save
>>> 32 WU, as you can't have NUMS-ness then. [3]
>>>
>>>
>>> 4. Higher network-wide full-node validation costs (checking a signature
>>> is quite more expensive than hashing, and the hashing is done in both
>>> cases).
>>>
>>>
>>> Are APO signatures more expensive to verify? If not i don't think this
>>> should be a reason to constrain us to a
>>> much less useful construction, as the cost for the network of validating
>>> signatures already exists today. Even
>>> if it didn't, the tradeoff of cost/usefulness needs to be considered.
>>>
>>>
>>> 5. As APO is currently spec'd, it would suffer from the half-spend
>>> problem: if you have multiple outputs encumbered under an APO covenant that
>>> requires the same tx sigmsg hash, it becomes possible to spend all of them
>>> together as multiple inputs in a single transaction and burn the extra to
>>> mining fees.
>>>
>>> If I'm not mistaken, I believe this makes the simple-apo-vault
>>> implementation [1] vulnerable to spending multiple vaulted outputs of the
>>> same denomination together and burning all but the first one. I asked the
>>> author for a more definitive answer on twitter [2].
>>>
>>> Fixing this requires amending BIP 118 with some new sigmsg flags (making
>>> the ANYONECANPAY behaviour optional, as mentioned in the OP).
>>>
>>>
>>> Yes! And as i mentioned on Twitter also committing to the input index
>>> which i forgot to add in the OP here.
>>>
>>>
>>> While i don't think the specific points are valid, i appreciate your
>>> reply and your efforts to explore the
>>> tradeoffs between the two approaches.
>>>
>>> Thanks,
>>> Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
>>> [1] https://bitcoin.stackexchange.com/a/91050/101498
>>> [2]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
>>> [3]
>>> https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
>>>
>>>
>>> This is definitely possible but also means that APO as-is isn't a
>>> CTV-replacement candidate, without first going through some more design and
>>> review iterations.
>>>
>>> shesek
>>>
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
>>> [1] https://github.com/darosior/simple-anyprevout-vault
>>> [2] https://twitter.com/shesek/status/1519874493434544128
>>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I would like to know people's sentiment about doing (a very slightly
>>>> tweaked version of) BIP118 in place of
>>>> (or before doing) BIP119.
>>>>
>>>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
>>>> over 6 years. It presents proven and
>>>> implemented usecases, that are demanded and (please someone correct me
>>>> if i'm wrong) more widely accepted than
>>>> CTV's.
>>>>
>>>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
>>>> optional [0], can emulate CTV just fine.
>>>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
>>>> expensive to use. But we can consider CTV
>>>> an optimization of APO-AS covenants.
>>>>
>>>> CTV advocates have been presenting vaults as the flagship usecase.
>>>> Although as someone who've been trying to
>>>> implement practical vaults for the past 2 years i doubt CTV is
>>>> necessary nor sufficient for this (but still
>>>> useful!), using APO-AS covers it. And it's not a couple dozen more
>>>> virtual bytes that are going to matter for
>>>> a potential vault user.
>>>>
>>>> If after some time all of us who are currently dubious about CTV's
>>>> stated usecases are proven wrong by onchain
>>>> usage of a less efficient construction to achieve the same goal, we
>>>> could roll-out CTV as an optimization. In
>>>> the meantime others will have been able to deploy new applications
>>>> leveraging ANYPREVOUT (Eltoo, blind
>>>> statechains, etc..[1]).
>>>>
>>>>
>>>> Given the interest in, and demand for, both simple covenants and better
>>>> offchain protocols it seems to me that
>>>> BIP118 is a soft fork candidate that could benefit more (if not most
>>>> of) Bitcoin users.
>>>> Actually i'd also be interested in knowing if people would oppose the
>>>> APO-AS part of BIP118, since it enables
>>>> CTV's features, for the same reason they'd oppose BIP119.
>>>>
>>>>
>>>> [0] That is, to not commit to the other inputs of the transaction (via
>>>> `sha_sequences` and maybe also
>>>> `sha_amounts`). Cf
>>>> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
>>>> .
>>>>
>>>> [1] https://anyprevout.xyz/ "Use Cases" section
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/8e6bc38d/attachment-0001.html>;

📅 Original date posted:2021-06-07 📝 Original ...

2023-06-07T22:54:14Z

In reply to nevent1q…hs4n
_________________________

📅 Original date posted:2021-06-07
📝 Original message:@SatoshiSingh PoLW sounds like a hybrid of PoW and proof of burn. I agree
with befreeandopen that proof of burn is basically a form of proof of
stake. My conclusion from this exploration
<https://github.com/fresheneesz/proofOfTimeOwnership>; is that hybrid
protocols are a dead end because hybrid protocols have one weaker link
that's easier to attack.

In this case, miners are burning coinbase rewards. The proof of stake is
the burn itself. However, a miner would only burn coins if doing so lead to
greater rewards in the future. So the burned coins are in fact actually
earned, and still have value. Therefore I would think that miners would
still do an amount of work totaling up to the full value of the block
reward, regardless of whether they burn it, because any burnt coins should
be expected to lead to more coins in the future than were burned. What am I
missing?

On Wed, Jun 2, 2021 at 10:30 PM SatoshiSingh <SatoshiSingh at protonmail.com>
wrote:

> Great conversation everyone. I'm happy we're still engaged with this
> discussion. To add food for thought I'm bringing back something that was
> introduced in this mailing list sometime ago, which is Proof of Less Work.
>
> PoLW may or may not be it but we can certainly get more ideas from it to
> keep the discussion going.
>
> https://raw.githubusercontent.com/alephium/research/master/polw.pdf
>
>
> Sent with ProtonMail Secure Email.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210606/1ff6314d/attachment-0001.html>;

📅 Original date posted:2021-05-21 📝 Original message:@Erik ...

2023-06-07T22:52:52Z

In reply to nevent1q…jm26
_________________________

📅 Original date posted:2021-05-21
📝 Original message:@Erik
> it also solves the "nothing at stake" problem

A. the "nothing at stake" problem can be and has been solved by PoS
consensus mechanisms (unless you mean it more broadly than I'm taking it),
and B. Proof of Burn should have just as much "nothing at stake" issues as
PoS. Both consensus mechanisms depend on the current state of the chain to
determine whether someone's stake or burn would allow the creation of a
block. But I am curious, how does proof of burn solve the "nothing at
stake" problem in your view?

On Fri, May 21, 2021 at 10:58 AM Erik Aronesty <erik at q32.com> wrote:

> proof of burn has all the benefits of proof of stake (if there are any)
>
> but it also solves the "nothing at stake" problem
>
> the incentive in POB is that you're making a long-term investment in
> mining, and you want a stable protocol, quality network, etc.... to
> pay off your investment.
>
> On Thu, May 20, 2021 at 8:04 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
> >
> > I think there is a lot of misinformation and bias against Proof of
> Stake. Yes there have been lots of shady coins that use insecure PoS
> mechanisms. Yes there have been massive issues with distribution of PoS
> coins (of course there have also been massive issues with PoW coins as
> well). However, I want to remind everyone that there is a difference
> between "proved to be impossible" and "have not achieved recognized success
> yet". Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
> >
> > @Eric Your proof of stake fallacy seems to be saying that PoS is worse
> when a 51% attack happens. While I agree, I think that line of thinking
> omits important facts:
> > * The capital required to 51% attack a PoS chain can be made
> substantially greater than on a PoS chain.
> > * The capital the attacker stands to lose can be substantially greater
> as well if the attack is successful.
> > * The effectiveness of paying miners to raise the honest fraction of
> miners above 50% may be quite bad.
> > * Allowing a 51% attack is already unacceptable. It should be considered
> whether what happens in the case of a 51% may not be significantly
> different. The currency would likely be critically damaged in a 51% attack
> regardless of consensus mechanism.
> >
> > > Proof-of-stake tends towards oligopolistic control
> >
> > People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
> >
> > > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
> >
> > I certainly agree. Bitcoin's energy usage at the moment is I think quite
> warranted. However, the question is: can we do substantially better. I
> think if we can, we probably should... eventually.
> >
> > > Proof of Stake is only resilient to ⅓ of the network demonstrating a
> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
> >
> > I see no mention of this in the pos.pdf you linked to. I'm not aware of
> any proof that all PoS systems have a failure threshold of 1/3. I know that
> staking systems like Casper do in fact have that 1/3 requirement. However
> there are PoS designs that should exceed that up to nearly 50% as far as
> I'm aware. Proof of work is not in fact resilient up to the 1/2 threshold
> in the way you would think. IE, if 100% of miners are currently honest and
> have a collective 100 exahashes/s hashpower, an attacker does not need to
> obtain 100 exahashes/s, but actually only needs to accumulate 50
> exahashes/s. This is because as the attacker accumulates hashpower, it
> drives honest miners out of the market as the difficulty increases to
> beyond what is economically sustainable. Also, its been shown that the best
> proof of work can do is require an attacker to obtain 33% of the hashpower
> because of the selfish mining attack discussed in depth in this paper:
> https://arxiv.org/abs/1311.0243. Together, both of these things reduce
> PoW's security by a factor of about 83% (1 - 50%*33%).
> >
> > > Proof of Stake requires other trade-offs which are incompatible with
> Bitcoin's objective (to be a trustless digital cash) — specifically the
> famous "security vs. liveness" guarantee
> >
> > Do you have a good source that talks about why you think proof of stake
> cannot be used for a trustless digital cash?
> >
> > > You cannot gain tokens without someone choosing to give up those coins
> - a form of permission.
> >
> > This is not a practical constraint. Just like in mining, some nodes may
> reject you, but there will likely be more that will accept you, some
> sellers may reject you, but most would accept your money as payment for
> bitcoins. I don't think requiring the "permission" of one of millions of
> people in the market can be reasonably considered a "permissioned currency".
> >
> > > 2. Proof of stake must have a trusted means of timestamping to
> regulate overproduction of blocks
> >
> > Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed
> to double their clock speeds. Both systems rely on an honest majority
> sticking to standard time.
> >
> >
> > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Ah sorry, I didn't realize this was, in fact, a different thread! :)
> >>
> >> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org>
> wrote:
> >>>
> >>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP
> itself. PoS, VDFs, and so on are interesting but I guess there are other
> threads going on these topics already where they would be relevant.
> >>>
> >>> Also, it's important to distinguish between oPoW and these other
> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
> the core game theory or security assumptions of Hashcash and actually
> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> >>>
> >>> Cheers,
> >>> Mike
> >>>
> >>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>
> >>>> 1. i never suggested vdf's to replace pow.
> >>>>
> >>>> 2. my suggestion was specifically *in the context of* a working
> >>>> proof-of-burn protocol
> >>>>
> >>>> - vdfs used only for timing (not block height)
> >>>> - blind-burned coins of a specific age used to replace proof of work
> >>>> - the required "work" per block would simply be a competition to
> >>>> acquire rewards, and so miners would have to burn coins, well in
> >>>> advance, and hope that their burned coins got rewarded in some far
> >>>> future
> >>>> - the point of burned coins is to mimic, in every meaningful way, the
> >>>> value gained from proof of work... without some of the security
> >>>> drawbacks
> >>>> - the miner risks losing all of his burned coins (like all miners risk
> >>>> losing their work in each block)
> >>>> - new burns can't be used
> >>>> - old burns age out (like ASICs do)
> >>>> - other requirements on burns might be needed to properly mirror the
> >>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
> >>>>
> >>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
> >>>> might be more secure in the long run, and that if the entire space
> >>>> agreed that such an endeavor was worthwhile, a test net could be spun
> >>>> up, and a hard-fork could be initiated.
> >>>>
> >>>> 4. i would never suggest such a thing unless i believed it was
> >>>> possible that consensus was possible. so no, this is not an "alt
> >>>> coin"
> >>>>
> >>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
> wrote:
> >>>> >
> >>>> > Hi ZmnSCPxj,
> >>>> >
> >>>> > Please note that I am not suggesting VDFs as a means to save
> energy, but solely as a means to make the time between blocks more constant.
> >>>> >
> >>>> > Zac
> >>>> >
> >>>> >
> >>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >>>> >>
> >>>> >> Good morning Zac,
> >>>> >>
> >>>> >> > VDFs might enable more constant block times, for instance by
> having a two-step PoW:
> >>>> >> >
> >>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being
> subject to difficulty adjustments similar to the as-is). As per the
> property of VDFs, miners are able show proof of work.
> >>>> >> >
> >>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
> block takes 1 minute on average, again subject to as-is difficulty
> adjustments.
> >>>> >> >
> >>>> >> > As a result, variation in block times will be greatly reduced.
> >>>> >>
> >>>> >> As I understand it, another weakness of VDFs is that they are not
> inherently progress-free (their sequential nature prevents that; they are
> inherently progress-requiring).
> >>>> >>
> >>>> >> Thus, a miner which focuses on improving the amount of energy that
> it can pump into the VDF circuitry (by overclocking and freezing the
> circuitry), could potentially get into a winner-takes-all situation,
> possibly leading to even *worse* competition and even *more* energy
> consumption.
> >>>> >> After all, if you can start mining 0.1s faster than the
> competition, that is a 0.1s advantage where *only you* can mine *in the
> entire world*.
> >>>> >>
> >>>> >> Regards,
> >>>> >> ZmnSCPxj
> >>>> _______________________________________________
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >>>
> >>>
> >>> --
> >>> Michael Dubrovsky
> >>> Founder; PoWx
> >>> www.PoWx.org
> >>
> >>
> >>
> >> --
> >> Michael Dubrovsky
> >> Founder; PoWx
> >> www.PoWx.org
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210521/0d41b5ee/attachment-0001.html>;

📅 Original date posted:2021-05-20 📝 Original message:I ...

2023-06-07T22:52:48Z

In reply to nevent1q…8aft
_________________________

📅 Original date posted:2021-05-20
📝 Original message:I think there is a lot of misinformation and bias against Proof of Stake.
Yes there have been lots of shady coins that use insecure PoS mechanisms.
Yes there have been massive issues with distribution of PoS coins (of
course there have also been massive issues with PoW coins as well).
However, I want to remind everyone that there is a difference between
"proved to be impossible" and "have not achieved recognized success yet".
Most of the arguments levied against PoS are out of date or rely on
unproven assumptions or extrapolation from the analysis of a particular PoS
system. I certainly don't think we should experiment with bitcoin by
switching to PoS, but from my research, it seems very likely that there is
a proof of stake consensus protocol we could build that has substantially
higher security (cost / capital required to execute an attack) while at the
same time costing far less resources (which do translate to fees on the
network) *without* compromising any of the critical security properties
bitcoin relies on. I think the critical piece of this is the disagreements
around hardcoded checkpoints, which is a critical piece solving attacks
that could be levied on a PoS chain, and how that does (or doesn't) affect
the security model.

@Eric Your proof of stake fallacy seems to be saying that PoS is worse when
a 51% attack happens. While I agree, I think that line of thinking omits
important facts:
* The capital required to 51% attack a PoS chain can be made substantially
greater than on a PoS chain.
* The capital the attacker stands to lose can be substantially greater as
well if the attack is successful.
* The effectiveness of paying miners to raise the honest fraction of miners
above 50% may be quite bad.
* Allowing a 51% attack is already unacceptable. It should be considered
whether what happens in the case of a 51% may not be significantly
different. The currency would likely be critically damaged in a 51% attack
regardless of consensus mechanism.

> Proof-of-stake tends towards oligopolistic control

People repeat this often, but the facts support this. There is no
centralization pressure in any proof of stake mechanism that I'm aware of.
IE if you have 10 times as much coin that you use to mint blocks, you
should expect to earn 10x as much minting revenue - not more than 10x. By
contrast, proof of work does in fact have clear centralization pressure -
this is not disputed. Our goal in relation to that is to ensure that the
centralization pressure remains insignifiant. Proof of work also clearly
has a lot more barriers to entry than any proof of stake system does. Both
of these mean the tendency towards oligopolistic control is worse for PoW.

> Energy usage, in-and-of-itself, is nothing to be ashamed of!!

I certainly agree. Bitcoin's energy usage at the moment is I think quite
warranted. However, the question is: can we do substantially better. I
think if we can, we probably should... eventually.

> Proof of Stake is only resilient to ⅓ of the network demonstrating a
Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold

I see no mention of this in the pos.pdf
<https://download.wpsoftware.net/bitcoin/pos.pdf>; you linked to. I'm not
aware of any proof that *all *PoS systems have a failure threshold of 1/3.
I know that staking systems like Casper do in fact have that 1/3
requirement. However there are PoS designs that should exceed that up to
nearly 50% as far as I'm aware. Proof of work is not in fact resilient up
to the 1/2 threshold in the way you would think. IE, if 100% of miners are
currently honest and have a collective 100 exahashes/s hashpower, an
attacker does not need to obtain 100 exahashes/s, but actually only needs
to accumulate 50 exahashes/s. This is because as the attacker accumulates
hashpower, it drives honest miners out of the market as the difficulty
increases to beyond what is economically sustainable. Also, its been shown
that the best proof of work can do is require an attacker to obtain 33% of
the hashpower because of the selfish mining attack
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack>;
discussed
in depth in this paper: https://arxiv.org/abs/1311.0243. Together, both of
these things reduce PoW's security by a factor of about 83% (1 - 50%*33%).

> Proof of Stake requires other trade-offs which are incompatible with
Bitcoin's objective (to be a trustless digital cash) — specifically the
famous "security vs. liveness" guarantee

Do you have a good source that talks about why you think proof of stake
cannot be used for a trustless digital cash?

> You cannot gain tokens without someone choosing to give up those coins -
a form of permission.

This is not a practical constraint. Just like in mining, some nodes may
reject you, but there will likely be more that will accept you, some
sellers may reject you, but most would accept your money as payment for
bitcoins. I don't think requiring the "permission" of one of millions of
people in the market can be reasonably considered a "permissioned
currency".

> 2. Proof of stake must have a trusted means of timestamping to regulate
overproduction of blocks

Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed to
double their clock speeds. Both systems rely on an honest majority sticking
to standard time.

On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>
> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org> wrote:
>
>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself.
>> PoS, VDFs, and so on are interesting but I guess there are other threads
>> going on these topics already where they would be relevant.
>>
>> Also, it's important to distinguish between oPoW and these other
>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
>> the core game theory or security assumptions of Hashcash and actually
>> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>
>> Cheers,
>> Mike
>>
>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> 1. i never suggested vdf's to replace pow.
>>>
>>> 2. my suggestion was specifically *in the context of* a working
>>> proof-of-burn protocol
>>>
>>> - vdfs used only for timing (not block height)
>>> - blind-burned coins of a specific age used to replace proof of work
>>> - the required "work" per block would simply be a competition to
>>> acquire rewards, and so miners would have to burn coins, well in
>>> advance, and hope that their burned coins got rewarded in some far
>>> future
>>> - the point of burned coins is to mimic, in every meaningful way, the
>>> value gained from proof of work... without some of the security
>>> drawbacks
>>> - the miner risks losing all of his burned coins (like all miners risk
>>> losing their work in each block)
>>> - new burns can't be used
>>> - old burns age out (like ASICs do)
>>> - other requirements on burns might be needed to properly mirror the
>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>>
>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>>> might be more secure in the long run, and that if the entire space
>>> agreed that such an endeavor was worthwhile, a test net could be spun
>>> up, and a hard-fork could be initiated.
>>>
>>> 4. i would never suggest such a thing unless i believed it was
>>> possible that consensus was possible. so no, this is not an "alt
>>> coin"
>>>
>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
>>> wrote:
>>> >
>>> > Hi ZmnSCPxj,
>>> >
>>> > Please note that I am not suggesting VDFs as a means to save energy,
>>> but solely as a means to make the time between blocks more constant.
>>> >
>>> > Zac
>>> >
>>> >
>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>> wrote:
>>> >>
>>> >> Good morning Zac,
>>> >>
>>> >> > VDFs might enable more constant block times, for instance by having
>>> a two-step PoW:
>>> >> >
>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject
>>> to difficulty adjustments similar to the as-is). As per the property of
>>> VDFs, miners are able show proof of work.
>>> >> >
>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
>>> block takes 1 minute on average, again subject to as-is difficulty
>>> adjustments.
>>> >> >
>>> >> > As a result, variation in block times will be greatly reduced.
>>> >>
>>> >> As I understand it, another weakness of VDFs is that they are not
>>> inherently progress-free (their sequential nature prevents that; they are
>>> inherently progress-requiring).
>>> >>
>>> >> Thus, a miner which focuses on improving the amount of energy that it
>>> can pump into the VDF circuitry (by overclocking and freezing the
>>> circuitry), could potentially get into a winner-takes-all situation,
>>> possibly leading to even *worse* competition and even *more* energy
>>> consumption.
>>> >> After all, if you can start mining 0.1s faster than the competition,
>>> that is a 0.1s advantage where *only you* can mine *in the entire world*.
>>> >>
>>> >> Regards,
>>> >> ZmnSCPxj
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Michael Dubrovsky
>> Founder; PoWx
>> www.PoWx.org <http://www.powx.org/>;
>>
>
>
> --
> Michael Dubrovsky
> Founder; PoWx
> www.PoWx.org <http://www.powx.org/>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210520/fec21169/attachment-0001.html>;