Nostr notes by

📅 Original date posted:2022-07-23 📝 Original message:+1 ...

2023-06-08T01:12:02+02:00

In reply to nevent1q…aans
_________________________

📅 Original date posted:2022-07-23
📝 Original message:+1 I'd participate.

Certain human/organizational limitations prevent things being said in
logged channels that sometimes can be shared in person. Sometimes
people break through misunderstandings in person, through either
informal mingling or the use of Chatham House rules. So I would also
advocate restarting the Scaling Bitcoin conferences, twice a year.

One request for the agenda:
I perceived a lot of "Oh, well it's also fine to just wait and see
what comes" in the prior discussions. The idea that we should reopen
this discussion presumes that it is better to not wait, because having
even imperfect covenant designs will cause the ecosystem to explore
what use cases to allocate developer interest in (as long as the fees
are not too far off - yeah I'm looking at you, CSFS). Because of
this, I also propose asking some of the more advanced scripting
technologists to reveal what of their work is currently science, what
is engineering, and what is product-oriented with understandable
delivery dates. I think that if more people understood the answers to
these questions then there would be more room for incremental
exploration of the space.

📅 Original date posted:2022-04-27 📝 Original message:We had ...

2023-06-08T01:08:29+02:00

In reply to nevent1q…ap0k
_________________________

📅 Original date posted:2022-04-27
📝 Original message:We had a UTXO proof-of-stake website at some point during the
blocksize wars. A few people signed with a few thousand bitcoins, but
it was clear that most were not participating. I don't have a link.

Another old discussion link:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-June/002731.html

Erik Aronesty listed good issues, a few minutes ago.

Other issues:
- you're feeding the Chainalysis beasts, when hodlers move their UTXOs;
- signalling should be weighted by Bitcoin Days Destroyed [ref_bdd];
- Coinbase.com's interests are not sufficiently aligned to poll them; and
- yuk, it's voting.

Without supporting voting, I wish to note there is also one more way
to de-Sybil, via network analysis, historically labeled the Web of
Trust. It can be algorithmically blinded so as not to fit strongly
into your "KYC" category, despite using assertions about people that
do know each other as a ground truth.

[ref_bdd:]
https://en.bitcoin.it/wiki/Bitcoin_Days_Destroyed

📅 Original date posted:2021-04-06 📝 Original message:On ...

2023-06-08T00:51:25+02:00

In reply to nevent1q…04vz
_________________________

📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The core question always was: what do we do if miners fail to activate?
>
> [...] Speedy Trial takes the approach that "let's pretend we didn't
> *actually* ask [miners]".

What ST is saying is that a strategy of avoiding unnecessary risk is
stronger than a strategy of brinkmanship when brinkmanship wasn't
our only option. Having deescalation in the strategy toolkit makes
Bitcoin stronger.

> It's totally a political approach, to avoid facing the awkward question.
> Since I believe that such prevaricating makes a future crisis less
> predictable, I am forced to conclude that it makes bitcoin less robust.

LOT=true does face the awkward question, but there are downsides:

- in the requirement to drop blocks from apathetic miners (although
as Luke-Jr pointed out in a previous reply on this list they have
no contract under which to raise a complaint); and

- in the risk of a chain split, should gauging economic majority
support - which there is zero intrinsic tooling for - go poorly.

> Personally, I think the compromise position is using LOT=false and
> having those such as Luke and myself continue working on a LOT=true
> branch for future consideration. It's less than optimal, but I
> appreciate that people want Taproot activated more than they want
> the groundwork future upgrades.

Another way of viewing the current situation is that should
brinkmanship be necessary, then better tooling to resolve a situation
that requires brinkmanship will be invaluable. But:

- we do not need to normalize brinkmanship;

- designing brinkmanship tooling well before the next crisis does
not require selecting conveniently completed host features to
strap the tooling onto for testing; and

- it's already the case that a UASF branch can be prepared along
with ST (ie. without requiring LOT=false), although the code is a
bit more complex and the appropriate stopheight a few blocks later.

Although your NACK is well explained, for the reasons above I am
prepared to run code that overrides it.

📅 Original date posted:2021-03-05 📝 Original message:On ...

2023-06-07T20:30:06+02:00

In reply to nevent1q…jagp
_________________________

📅 Original date posted:2021-03-05
📝 Original message:On Fri, Mar 5, 2021 at 9:39 AM Lonero Foundation via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello, I want to start a new BIP proposal aiming to tackle some of
> the energy efficiency issues w/ Bitcoin mining. Excuse my ignorance
> given this is my first time making a BIP proposal, but is there a
> specific format I need to follow?

Hi Andrew,

I would like to discourage you from writing a BIP on this topic, as
any such proposal is guaranteed to be rejected based on prior
discussions in the community.

Please update your priors with the following:

https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
BIP: 2
Title: BIP process, revised

https://www.truthcoin.info/blog/pow-cheapest/
"Nothing is Cheaper than Proof of Work"
on | 04 Aug 2015

Your topic brings up an interesting edge case, which is whether the
BIP repository is an open forum for all possible arguments that are
technically well constructed. Obviously: no; but by what
non-arbitrary process do we decide?

I propose that the BIP Editor's role should include preserving signal
in the table of contents generated from our proposal repository, by
unilaterally rejecting - without any fuhrer comment - technically well
constructed proposals which are guaranteed to be rejected based on
prior discussions in the community, as spam. I think this is already
how it works, but we haven't actually written down this part of the
norms.

Since censorship is always a concern, it would be appropriate to
maintain a moderation log of spam BIPs, so that observers could judge
whether the BIP Editor is misusing the BIP assignment process to
censor proposals with some merit. Since one of the requirements for
submitting a BIP is to notify bitcoin-dev, the log is already
maintained. Since bitcoin-dev is moderated, the moderators take on a
low level of responsibility for gauging spam proposals (and they are
pretty relaxed about it, since it is better to err on the side of
inclusion for new developers, except for obvious patent bombing).
Since the bitcoin-dev moderation log is public and anyone can
subscribe to it, protective transparency is again achieved.

https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/

📅 Original date posted:2018-08-16 📝 Original message:On ...

2023-06-07T20:14:02+02:00

In reply to nevent1q…rn7w
_________________________

📅 Original date posted:2018-08-16
📝 Original message:On Wed, Aug 15, 2018 at 8:40 PM, Jude Nelson via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Can a miner identify which transactions came from your software simply by
> running a copy themselves? If so, then they can censor your transactions no
> matter how you encode them.

The hash of the file is deterministic and `ipfs add` tells us what it
is whether the network is connected or disconnected. We don't upload
files to IPFS until the transaction has settled with several
confirmations.

📅 Original date posted:2017-04-07 📝 Original message:The ...

2023-06-07T19:59:31+02:00

In reply to nevent1q…hymz
_________________________

📅 Original date posted:2017-04-07
📝 Original message:The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.

If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.