Nostr notes by Jeremy [ARCHIVE]

📅 Original date posted:2021-09-06 📝 Original message:BIP 68 ...

2023-06-07T22:58:40Z

In reply to nevent1q…aqea
_________________________

📅 Original date posted:2021-09-06
📝 Original message:BIP 68 says >= 2:
*This specification defines the meaning of sequence numbers for
transactions with an nVersion greater than or equal to 2 for which the rest
of this specification relies on.*
BIP-112 says not < 2
// Fail if the transaction's version number is not set high
// enough to trigger BIP 68 rules.
if (static_cast<uint32_t>(txTo->nVersion) < 2) return false;

A further proof that this needs fix: the flawed upgradable semantic exists
in script as well as in the transaction nSeqeunce. we can't really control
the transaction version an output will be spent with in the future, so it
would be weird/bad to change the semantic in transaction version 3.

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Sun, Sep 5, 2021 at 7:36 PM David A. Harding <dave at dtrt.org> wrote:

> On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
> > Hi Bitcoin Devs,
> >
> > I recently noticed a flaw in the Sequence lock implementation with
> respect
> > to upgradability. It might be the case that this is protected against by
> > some transaction level policy (didn't see any in policy.cpp, but if not,
> > I've put up a blogpost explaining the defect and patching it
> > https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
>
> Isn't this why BIP68 requires using tx.version=2? Wouldn't we just
> deploy any new nSequence rules with tx.version>2?
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210905/036b421e/attachment.html>;

📅 Original date posted:2021-09-04 📝 Original message:Hi ...

2023-06-07T22:58:39Z

In reply to nevent1q…gd9l
_________________________

📅 Original date posted:2021-09-04
📝 Original message:Hi Bitcoin Devs,

I recently noticed a flaw in the Sequence lock implementation with respect
to upgradability. It might be the case that this is protected against by
some transaction level policy (didn't see any in policy.cpp, but if not,
I've put up a blogpost explaining the defect and patching it
https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/

I've proposed patching it here https://github.com/bitcoin/bitcoin/pull/22871,
it is proper to widely survey the community before patching to ensure no
one is depending on the current semantics in any live application lest this
tightening of standardness rules engender a confiscatory effect.

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210903/1d2d16a4/attachment.html>;

📅 Original date posted:2021-09-05 📝 Original message:In ...

2023-06-07T22:58:39Z

In reply to nevent1q…uwyy
_________________________

📅 Original date posted:2021-09-05
📝 Original message:In working on resolving this issue, one issue that has come up is what
sequence values get used by wallet implementations?

E.g., in Bitcoin Core a script test says

BIP125_SEQUENCE_NUMBER = 0xfffffffd # Sequence number that is rbf-opt-in
(BIP 125) and csv-opt-out (BIP 68)

Are any other numbers currently expected by any wallet software to be
broadcastable with the DISABLE flag set? Does anyone use *this* number? Is
there any advantage of this number v.s. just 0? Do people commonly use
0xfffffffd? 0xfffffffe is special, but it seems the former has the
alternative of either 0 valued sequence lock (1<<22 or 0).

Are there any other sequence numbers that are not defined in a BIP that
might be used somewhere?

Cheers,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Fri, Sep 3, 2021 at 8:32 PM Jeremy <jlrubin at mit.edu> wrote:

> Hi Bitcoin Devs,
>
> I recently noticed a flaw in the Sequence lock implementation with respect
> to upgradability. It might be the case that this is protected against by
> some transaction level policy (didn't see any in policy.cpp, but if not,
> I've put up a blogpost explaining the defect and patching it
> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
>
> I've proposed patching it here
> https://github.com/bitcoin/bitcoin/pull/22871, it is proper to widely
> survey the community before patching to ensure no one is depending on the
> current semantics in any live application lest this tightening of
> standardness rules engender a confiscatory effect.
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210904/036089ac/attachment.html>;

📅 Original date posted:2021-05-10 📝 Original message:re: 2, ...

2023-06-07T22:52:44Z

In reply to nevent1q…q8c3
_________________________

📅 Original date posted:2021-05-10
📝 Original message:re: 2, there's been some promising developments with Verifiable Delay
Functions that make me think that the block regulation problems are
solvable without requiring brute-force search proof of work. Are those
inapplicable for some reason?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210510/ec6b1926/attachment.html>;

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

2023-06-07T22:52:38Z

In reply to nevent1q…534g
_________________________

📅 Original date posted:2021-05-07
📝 Original message:Proof-of-stake tends towards oligopolistic control, which is antithetical
to bitcoin.

Proof-of-stake also has some other security issues that make it a bad
substitute for Proof-of-work with respect to equivocation (reorgs).

Overall you'll find me *personally* in the camp that it's OK to explore
non-PoW means of consensus long term that can keep the network in consensus
in a more capital efficient manner, but that proof-of-stake is not such a
substitute. Other Bitcoiners will disagree with this invariably, but if you
truly have a novel solution for Byzantine Generals, it would be a major
contribution to not just Bitcoin but the field of computer science as a
whole and would likely get due consideration.

What's difficult is that Bitcoin PoW has some very specific properties that
may or may not be desirable around e.g. fairness that might be difficult to
ensure in other systems, so there is probably more to the puzzle than just
consensus.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Fri, May 7, 2021 at 3:50 PM SatoshiSingh via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello list,
>
> I am a lurker here and like many of you I worry about the energy usage of
> bitcoin mining. I understand a lot mining happens with renewable resources
> but the impact is still high.
>
> I want to get your opinion on implementing proof of stake for bitcoin
> mining in future. For now, proof of stake is still untested and not battle
> tested like proof of work. Though someday it will be.
>
> In the following years we'll be seeing proof of stake being implemented.
> Smaller networks can test PoS which is a luxury bitcoin can't afford.
> Here's how I see this the possibilities:
>
> 1 - Proof of stake isn't a good enough security mechanism
> 2 - Proof of state is a good security mechanism and works as intended
>
> IF PoS turns out to be good after battle testing, would you consider
> implementing it for Bitcoin? I understand this would invoke a lot of
> controversies and a hard fork that no one likes. But its important enough
> to consider a hard fork. What are your opinions provided PoS does work?
>
> Love from India.
> _______________________________________________
> 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/20210507/bdc3653f/attachment.html>;

📅 Original date posted:2021-03-15 📝 Original message:I ...

2023-06-07T18:30:51Z

In reply to nevent1q…rygq
_________________________

📅 Original date posted:2021-03-15
📝 Original message:I think Luke is pointing out that with the Signature and the Message you
should be able to recover the key.

if your address is H(P) and the message is H(H(P) || txn), then the you can
use the public H(P) and the signature to recover the PK and verify that
H(P) == P (I think you then don't even have to check the signature after
doing that).

Therefore there is no storage benefit.

For the script path case, you might have to pay a little bit extra though
as you'd have to reveal P I think? But perhaps that can be avoided another
way...
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;

On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause"
> while a
> > full quantum-safe fix is developed, and then resume transacting. With
> Taproot
> > as-is, it could very well become an unrecoverable situation if QC go
> online
> > prior to having a full quantum-safe solution.
>
> This has been discussed ad nauseam, and it all seems to fall apart once
> its noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause"
> can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't
> anything that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > Also, what I didn't know myself until today, is that we do not actually
> gain
> > anything from this: the features proposed to make use of the raw keys
> being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for
> anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at
> worst, it
> > would create an incentive for more people to use their own full node,
> which
> > is a good thing!
>
> This is untrue. The storage space required for Taproot transactions is
> materially reduced by avoiding the hash indirection.
>
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> should be
> > fairly trivial to add a hash on top in an additional softfork and fix
> this.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at
> least nine years and still haven't solved it.
> Worse, there's a lot of old coins that are unlikely to move any time soon
> that are exposed whether we like it or not.
>
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it
> can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've
> seen
> > far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of
> supply rather quickly (presumably over the course
> of a few days, at maximum), instead of a slow process with significant
> upfront real-world cost in the form of electricity.
> _______________________________________________
> 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/20210315/7b7aea3f/attachment-0001.html>;