Nostr notes by yanmaani at cock.li [ARCHIVE]

📅 Original date posted:2022-02-13 📝 Original message:On ...

2023-06-07T23:03:54Z

In reply to nevent1q…6m3g
_________________________

📅 Original date posted:2022-02-13
📝 Original message:On 2022-02-07 14:34, Billy Tetrud via bitcoin-dev wrote:
> I do think that UTXO set size is something that will need to be
> addressed at some point. I liked the idea of utreexo or some other
> accumulator as the ultimate solution to this problem.

What about using economic incentives to disincentivize the creation of
new UTXOs? Currently, the fee is only charged per byte of space. What if
you instead charged a fee of (bytes*byte_weight +
net_utxos*utxo_weight)? For example, if utxo_weight=500, then a
transaction that creates 2 new UTXOs would cost as if it were 1 KB in
size. And a transaction that consolidated 2 UTXOs into one might even
get a negative transaction fee (rebate).

Technologically, you'd implement this by lowering the block size cap by
max(0, net_utxos_created*utxo_weight). That would be a soft fork, if
maybe a contentious one. It's probably also a good idea to limit it at
0, separate from consensus issues, because it means you're not
guaranteed to get back whatever you put into it.

📅 Original date posted:2021-12-15 📝 Original message:How ...

2023-06-07T23:01:27Z

In reply to nevent1q…58a3
_________________________

📅 Original date posted:2021-12-15
📝 Original message:How does this differ from p2pool?

If you've just re-invented p2pool, shouldn't you credit their prior art?

Monero is doing their implementation of p2pool. They have viable solo
mining, as far as I understand. The basic idea is you have several
P2pools. If you have a block time of 10 minutes, p2pool has 20% of
hashrate, and there's 100 p2pool chains, each chain gets 0.2% of net
hash. If you're OK with 20s block times (orphans aren't really a big
problem), you need (20/600) * (0.02/100) = 0.00067% of network hash to
get a payout every 10m.

📅 Original date posted:2021-10-27 📝 Original message:[I ...

2023-06-07T23:00:23Z

In reply to nevent1q…5g87
_________________________

📅 Original date posted:2021-10-27
📝 Original message:[I removed a comment regarding the moderation of this list here because
it caused for my message to be rejected]

On 2021-10-26 02:56, lisa neigut via bitcoin-dev wrote:
> [...] the mempool is obsolete and should be eliminated.
>
> Instead, users should submit their transactions directly to mining
> pools, [...]
> Mempools make sense in a world where mining is done by a large number
> of participating nodes, [...] as you don’t know which participant will
> be constructing the winning block template.
>
> In reality however, mempool relay is unnecessary where the majority of
> hashpower and thus block template creation is concentrated in a
> semi-restricted set.

It's true that there is some centralization, but this is hardly a
desirable goal that should be formally enshrined.

By that point, you might as well block people from keeping their coins
in their own wallet, on the basis that in practice mostly everyone keeps
them on the exchange.

And as the others have pointed out: even if you did hold this to be
desirable, why would removing the mempool be a good idea? The pools
would still need some way to get transactions, and a mempool seems like
an excellent way to do this.

I think most of the people here have laid out all of the other obvious
issues with the proposal.

> Removing the mempool would greatly reduce the bandwidth requirement
> for running a node

You can disable it already if you're strapped for cash. Is there a
reason why this is not adequate?

> keep intentionality of transactions private until confirmed/irrevocable

What is the "intentionality" of a transaction and why do I want to keep
it private? My transactions are 100% intentional because I am trying to
send money, and I wouldn't make them otherwise - what is a
non-intentional transaction supposed to be?

> Provided the number of block template producing actors remains
> beneath, say 1000, it’d be quite feasible to publish a list of tor
> endpoints that nodes can independently + directly submit their
> transactions to.

If nothing else, this would be a significant departure from the security
model of Bitcoin:

> The network is robust in its unstructured simplicity.
> Nodes work all at once with little coordination.
> They do not need to be identified, since messages are not routed to any
> particular place and only need to be delivered on a best effort basis.
> Nodes can leave and rejoin the network at will, accepting the
> proof-of-work chain as proof of what happened while they were gone.

If you posit that the security model should be changed, that is one
thing, but you should lay out your reasoning for this claim.

> On the other hand, removing the mempool would greatly complicate solo
> mining and would also make BetterHash proposals, which move the block
> template construction away from a centralized mining pool back to the
> individual miner, much more difficult.

I am amazed that you are intelligent enough to realize these trade-offs,
yet still made this post. Are you suggesting that you find them to be
acceptable?

> It also makes explicit the target for DoS attacks.

Perhaps the only good aspect of this proposal. Under such conditions,
denial of service attacks would be both just and desirable.

> A direct communication channel between block template construction
> venues and transaction proposers also provides a venue for direct
> feedback wrt acceptable feerates at the time, which both makes
> transaction confirmation timelines less variable as well as provides
> block producers a mechanism for (independently) enforcing their own
> minimum security budget. In other words, expressing a minimum
> acceptable feerate for continued operation.

Why couldn't they just run a website about this for anyone who cares?
Communicating two numbers can easily be done over HTTP. This technology
exists already.

> ~niftynei
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-10-17 📝 Original message:Well, ...

2023-06-07T23:00:09Z

In reply to nevent1q…e99t
_________________________

📅 Original date posted:2021-10-17
📝 Original message:Well, it's the right word. If you're going to do a hardfork by changing
the timestamp definition, you're already doing a hardfork. At that
point, you've already crossed the Rubicon and might as well put in any
other necessary changes (e.g. to transaction locking), because it will
be as much of a hardfork either way.

The important bit here is "as long as it doesn't change anything now" -
this is indeed a hardfork, but it's a timestamp-activated hardfork that
triggers in 2106. Until that point, it has absolutely no bearing on
consensus rules (as opposed to the other proposals, which are at least a
soft-fork today).

I understand that there's some problems in getting consensus for forks,
but surely we can agree that everyone will update their Bitcoin at least
once in the next 85 years? (If they don't, they're doomed anyway.)

On 2021-10-17 15:46, Kate Salazar wrote:
> Hi yanmaani
>
...
>> This is a hardfork, yes, but it's a hardfork that kicks in way into
>> the
>> future. And because it's a hardfork, you might as well do anything,
>> as
>> long as it doesn't change anything now.
>
> "Anything" is quite a word.
> Ideally, hard fork requires upgrading every node that can be upgraded,
>
> or at least have the node operator's consent to lose the node (for
> every
> node that can't be upgraded).
>
...
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-10-17 📝 Original message:What, ...

2023-06-07T23:00:09Z

In reply to nevent1q…fv82
_________________________

📅 Original date posted:2021-10-17
📝 Original message:What, no. The `k` value is calculated implicitly, because there's only
one value of it that could ever be valid - if `k` is 1 too small, we're
70 years too far back, and then the block will violate median of last
11. If `k` is 1 too large, we're 70 years too far in the future, then
the block will violate 2 hour rule. Nothing is added to coinbase or
anywhere else.

It's possible that you'd need some extra logic for locktime, yes, but it
would only be a problem in very special cases. Worst-case, you'll have
to use block time locking in the years around the switch, or softfork in
64-bit locking.

But unless I'm missing something, 32-bit would be enough, you just
wouldn't be able to locktime something past the timestamp for the
switch. After the switchover, everything would be back to normal.

This is a hardfork, yes, but it's a hardfork that kicks in way into the
future. And because it's a hardfork, you might as well do anything, as
long as it doesn't change anything now.

On 2021-10-15 22:22, vjudeu at gazeta.pl wrote:
> Your solution seems to solve the problem of chain halting, but there
> are more issues. For example: if you have some time modulo 2^32, then
> you no longer know if timestamp zero is related to 1970 or 2106 or
> some higher year. Your "k" value representing in fact the most
> significant 32 bits of 64-bit timestamp has to be stored in all cases
> where time is used. If there is no "k", then zero should be used for
> backward compatibility. Skipping "k" could cause problems related to
> OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was
> timestamped to 0xbadc0ded, then that transaction will be valid in
> 0x00000000badc0ded, invalid in 0x0000000100000000, and valid again in
> 0x00000001badc0ded, the same for timelocked outputs.
>
> So, I think your "k" value should be added to the coinbase
> transaction, then you can combine two 32-bit values, the lower bits
> from the block header and the higher bits from the coinbase
> transaction. Also, adding your "k" value transaction nLockTime field
> is needed (maybe in a similar way as transaction witness was added in
> Segwit), because in other case after reaching 0x0000000100000000 all
> off-chain transactions with timelocks around 0x00000000ffffffff will
> be additionally timelocked for the next N years. The same is needed
> for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the
> currently used value will solve that (and assuming zero if there is
> only some 32-bit value).

📅 Original date posted:2021-10-15 📝 Original ...

2023-06-07T23:00:07Z

In reply to nevent1q…6m5q
_________________________

📅 Original date posted:2021-10-15
📝 Original message:It's well-known. Nobody really cares, because it's so far off. Not
possible to do by softfork, no. It is possible to do by something that
becomes a hardfork in 80 years, though, which is probably good enough.

I proposed a solution, but nobody was really interested. Let's see if
anyone bites now.

---

Subject: Suggestion: Solve year 2106 problem by taking timestamps mod
2^32
To Bitcoin Protocol Discussion
Date 2020-09-19 12:36
Message Body
Currently, Bitcoin's timestamp rules are as follows:

1. The block timestamp may not be lower than the median of the last 11
blocks'
2. The block timestamp may not be greater than the current time plus two
hours
3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
06:28:16 +0000)

Thus, Bitcoin will "die" on or about 2106-02-07, when there is no
timestamp below 2^32 that exceeds the median of the last 11 blocks.

If the rules were changed to the following, this problem would be
solved:

1. The block timestamp plus k*2^32 may not be lower than the median of
the last 11 blocks'
2. The block timestamp plus k*2^32 may not be greater than the current
time plus two hours
3. k is an integer, whose value must be the same for the calculations of
Rule 1 and Rule 2

This would cause a hardfork in the year 2106, which is approximately
85.5 years from now, by which time 95% of nodes would hopefully have
updated.

Another proposed solution is 64-bit timestamps. They would break
compatibility with other software that has specific expectations of
header fields, like ASICs' firmware. They would also cause a hardfork
before the date of timestamp overflow. I thus believe them to be a less
appropriate solution.

What do you think of this idea? Is it worth a BIP?

On 2021-10-13 19:16, vjudeu via bitcoin-dev wrote:
> It seems that Bitcoin Core will stop working in 2038 because of
> assertion checking if the current time is non-negative. Also, the
> whole chain will halt after reaching median time 0xffffffff in 2106.
> More information: https://bitcointalk.org/index.php?topic=5365359.0
>
> I wonder if that kind of issues are possible to fix in a soft-fork
> way.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-06-24 📝 Original message:No, ...

2023-06-07T22:54:20Z

In reply to nevent1q…de6r
_________________________

📅 Original date posted:2021-06-24
📝 Original message:No, that's not how it works.

PoS is constitutionally incapable of producing any further consensus
from its starting point. If you start out by hardcoding the bitcoin
ledger state at June 1, 2021, then your PoS system will be unable to
reach a global consensus as to what the state was on June 2, 2021.

To get global consensus in PoS, you have to know which block came first.
To reach a consensus on which block was first, you need to solve the
timestamp problem. And to solve the timestamp problem, you need a
consensus system. You'll notice that at no point does PoS provide such a
consensus system.

Implementations of PoS sacrifice global consensus for 'weak
subjectivity', meaning that each node has its own notion of when a
certain block arrived. Astute observers will note that 'each node has
its own notion of what happened' differs somewhat from 'all nodes agree
on what happened', and that only one of these is a good description of
what is commonly known as 'consensus'.

Maybe a simpler way of looking at it is from the coder's perspective:
how do you implement IBD? In PoW, the "longest chain" rule is used -
"Nodes can leave and rejoin the network at will, accepting the
proof-of-work chain as proof of what happened while they were gone.".
Does PoS have this property?

On 2021-06-24 21:50, Erik Aronesty wrote:
>> PoS is not suitable for use as a consensus system, because
> it is constitutionally incapable of producing a consensus.
>
> true - but only for a system that is starting from nothing.
>
> since bitcoin already exists, and we have a consensus, you can use
> bitcoin's existing consensus to maintain that consensus using
> references to prior state. and yes, you simply have to limit reorgs
> to not go back before PoW was abandoned in favor of PoS/PoB (assuming
> all incentive problems are solved).
>
> ie: once you have uses PoW to bootstrap the system, you can "recycle"
> that work.
>
> On Thu, Jun 24, 2021 at 4:41 PM yanmaani--- via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> No, 51% of the *coin holders* can't do diddly squat. 51% of miners
>> can,
>> but in PoW, that's a different set to the coin holders.
>>
>> The basic problem with PoS, anyway, is that it's not actually a
>> consensus system ("weak subjectivity"). Either you allow long reorgs,
>> and then you open the door to long-range attacks, or you don't, and
>> then
>> you're not guaranteed that all nodes agree on the state of the chain,
>> which was the purpose of the system to begin with.
>>
>> To put it more plainly: for PoS to work, you need a consensus on which
>> block was seen first. But if you had that, you could presumably apply
>> that method to determine which *transaction* was seen first, in which
>> case you could do away with the blockchain entirely. (Real-world
>> implementations of PoS, such that they are, do away with this
>> requirement, scrapping the global consensus on ordering in favor of
>> having each node decide for itself which block came first.)
>>
>> In other words, even if you solved all the incentive problems, the
>> fact
>> remains that PoS is not suitable for use as a consensus system,
>> because
>> it is constitutionally incapable of producing a consensus.
>>
>> On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
>> >> This is not true in a Proof of Work system and this difference
>> > absolutely should not be trivialized.
>> >
>> > That is in fact true of Proof of Work as well. If a colluding
>> > coalition of miners with more than 50% of the hashrate want to censor
>> > transactions, they absolutely can do that by orphaning blocks that
>> > contain transactions they want to censor. This is not different in
>> > proof of stake.
>> >
>> > On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
>> > <keagan.mcclelland at gmail.com> wrote:
>> >
>> >>> Premise: There is a healthy exchange market for PoS Coin X with
>> >> tens of thousands of participants bidding to buy and sell the coin
>> >> for other currencies on the market.
>> >>
>> >> The difference here though is that Proof of Stake allows the quorum
>> >> of coin holders to block the exchange of said coins if they are
>> >> going to a particular destination. Nothing requires these staking
>> >> nodes to include particular transactions into a block. With that in
>> >> mind, it isn't just that you require the permission of the person
>> >> who sold you the coins, which I can agree is a less dangerous form
>> >> of permission, but you must also require the permission of at least
>> >> 51% of the coin holders to even receive those coins in the first
>> >> place. This is not true in a Proof of Work system and this
>> >> difference absolutely should not be trivialized.
>> >>
>> >> Keagan
>> >>
>> >> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >>> Barrier to entry in PoS is being given permission by the previous
>> >> owner of a token
>> >>
>> >> The idea that proof of stake is not permissionless is completely
>> >> invalid. It pains me to see such an argument here. Perhaps we can
>> >> come to an agreement by being more specific. I'd like to propose the
>> >> following:
>> >>
>> >> Premise: There is a healthy exchange market for PoS Coin X with tens
>> >> of thousands of participants bidding to buy and sell the coin for
>> >> other currencies on the market.
>> >>
>> >> If the premise above is true, then there is no significant
>> >> permission needed to enter the market for minting blocks for PoS
>> >> Coin X. If you make a bid on someone's coins and they don't like you
>> >> and refuse, you can move on to any one of the other tens of
>> >> thousands of people in that marketplace. Would you agree, Cloud
>> >> Strife, that this situation couldn't be considered "permissioned"?
>> >>
>> >> If not, consider that participation in *any* decentralized system
>> >> requires the permission of at least one user in that system. If
>> >> there are thousands of bitcoin public nodes, you require the
>> >> permission of at least one of them to participate in bitcoin. No one
>> >> considers bitcoin "permissioned" because of this. Do you agree?
>> >>
>> >> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> Barrier to entry in PoW is matter for hardware and energy is
>> >> permissionless and exist all over the universe, permissionless cost
>> >> which exists for everyone no matter who because it's unforgeable.
>> >>
>> >> Barrier to entry in PoS is being given permission by the previous
>> >> owner of a token for you to have it via transfer or sale, both
>> >> choices they never have to make since there are no continuous costs
>> >> with producing blocks forcing it. A permission is an infinitely high
>> >> barrier to entry if the previous owner, like the premining party,
>> >> refuses to give up the token they control.
>> >>
>> >> You're skipping the part where you depend on a permission of a
>> >> central party in control of the authority token before you can
>> >> produce blocks on your rasberry Pi.
>> >>
>> >> Proof of stake is not in any possible way relevant to permissionless
>> >> protocols, and thus not possibly relevant to decentralized protocols
>> >> where control must be distributed to independent (i.e.
>> >> permissionless) parties.
>> >>
>> >> There's nothing of relevance to discuss and this has been figured
>> >> out long long ago.
>> >>
>> >>
>> > https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>> >>
>> >>
>> > https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca
>> >>
>> >> On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> @Lloyd wrote:
>> >>
>> >> Of course in reality no one wants to keep their coin holding keys
>> >> online so in Alogorand you can authorize a set of "participation
>> >> keys"[1] that will be used to create blocks on your coin holding
>> >> key's behalf.
>> >> Hopefully you've spotted the problem.
>> >> You can send your participation keys to any malicious party with a
>> >> nice website (see random example [2]) offering you a good return.
>> >> Damn it's still Proof-of-SquareSpace!
>> >>
>> >> I believe we are talking about a comparison to PoW, correct? If you
>> >> want to mine PoW, you need to buy expensive hardware and configure
>> >> it to work, and wait a long time to get any return by solo mining.
>> >> Or you can join a mining pool, which might use your hashing power
>> >> for nefarious purposes. Or you might skip the hardware all together
>> >> and fall for some "cloud mining" scheme with a pretty website and a
>> >> high rate of advertised return. So as you can see,
>> >> Proof-of-SquareSpace exists in PoW as well!
>> >>
>> >> The PoS equivalent of buying mining hardware is setting up your own
>> >> validator and not outsourcing that to anyone else. So both PoW and
>> >> PoS have the professional/expert way of participating, and the
>> >> fraud-prone, amateur way of participating. The only difference is,
>> >> with PoS the professional/expert way is accessible to anyone with a
>> >> raspberry Pi and a web connection, which is a much lower barrier to
>> >> entry than PoW. _______________________________________________
>> >> 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
>> > _______________________________________________
>> > 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
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-06-24 📝 Original message:No, ...

2023-06-07T22:54:18Z

In reply to nevent1q…wfu3
_________________________

📅 Original date posted:2021-06-24
📝 Original message:No, 51% of the *coin holders* can't do diddly squat. 51% of miners can,
but in PoW, that's a different set to the coin holders.

The basic problem with PoS, anyway, is that it's not actually a
consensus system ("weak subjectivity"). Either you allow long reorgs,
and then you open the door to long-range attacks, or you don't, and then
you're not guaranteed that all nodes agree on the state of the chain,
which was the purpose of the system to begin with.

To put it more plainly: for PoS to work, you need a consensus on which
block was seen first. But if you had that, you could presumably apply
that method to determine which *transaction* was seen first, in which
case you could do away with the blockchain entirely. (Real-world
implementations of PoS, such that they are, do away with this
requirement, scrapping the global consensus on ordering in favor of
having each node decide for itself which block came first.)

In other words, even if you solved all the incentive problems, the fact
remains that PoS is not suitable for use as a consensus system, because
it is constitutionally incapable of producing a consensus.

On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
>> This is not true in a Proof of Work system and this difference
> absolutely should not be trivialized.
>
> That is in fact true of Proof of Work as well. If a colluding
> coalition of miners with more than 50% of the hashrate want to censor
> transactions, they absolutely can do that by orphaning blocks that
> contain transactions they want to censor. This is not different in
> proof of stake.
>
> On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
> <keagan.mcclelland at gmail.com> wrote:
>
>>> Premise: There is a healthy exchange market for PoS Coin X with
>> tens of thousands of participants bidding to buy and sell the coin
>> for other currencies on the market.
>>
>> The difference here though is that Proof of Stake allows the quorum
>> of coin holders to block the exchange of said coins if they are
>> going to a particular destination. Nothing requires these staking
>> nodes to include particular transactions into a block. With that in
>> mind, it isn't just that you require the permission of the person
>> who sold you the coins, which I can agree is a less dangerous form
>> of permission, but you must also require the permission of at least
>> 51% of the coin holders to even receive those coins in the first
>> place. This is not true in a Proof of Work system and this
>> difference absolutely should not be trivialized.
>>
>> Keagan
>>
>> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Barrier to entry in PoS is being given permission by the previous
>> owner of a token
>>
>> The idea that proof of stake is not permissionless is completely
>> invalid. It pains me to see such an argument here. Perhaps we can
>> come to an agreement by being more specific. I'd like to propose the
>> following:
>>
>> Premise: There is a healthy exchange market for PoS Coin X with tens
>> of thousands of participants bidding to buy and sell the coin for
>> other currencies on the market.
>>
>> If the premise above is true, then there is no significant
>> permission needed to enter the market for minting blocks for PoS
>> Coin X. If you make a bid on someone's coins and they don't like you
>> and refuse, you can move on to any one of the other tens of
>> thousands of people in that marketplace. Would you agree, Cloud
>> Strife, that this situation couldn't be considered "permissioned"?
>>
>> If not, consider that participation in *any* decentralized system
>> requires the permission of at least one user in that system. If
>> there are thousands of bitcoin public nodes, you require the
>> permission of at least one of them to participate in bitcoin. No one
>> considers bitcoin "permissioned" because of this. Do you agree?
>>
>> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Barrier to entry in PoW is matter for hardware and energy is
>> permissionless and exist all over the universe, permissionless cost
>> which exists for everyone no matter who because it's unforgeable.
>>
>> Barrier to entry in PoS is being given permission by the previous
>> owner of a token for you to have it via transfer or sale, both
>> choices they never have to make since there are no continuous costs
>> with producing blocks forcing it. A permission is an infinitely high
>> barrier to entry if the previous owner, like the premining party,
>> refuses to give up the token they control.
>>
>> You're skipping the part where you depend on a permission of a
>> central party in control of the authority token before you can
>> produce blocks on your rasberry Pi.
>>
>> Proof of stake is not in any possible way relevant to permissionless
>> protocols, and thus not possibly relevant to decentralized protocols
>> where control must be distributed to independent (i.e.
>> permissionless) parties.
>>
>> There's nothing of relevance to discuss and this has been figured
>> out long long ago.
>>
>>
> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>>
>>
> https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca
>>
>> On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> @Lloyd wrote:
>>
>> Of course in reality no one wants to keep their coin holding keys
>> online so in Alogorand you can authorize a set of "participation
>> keys"[1] that will be used to create blocks on your coin holding
>> key's behalf.
>> Hopefully you've spotted the problem.
>> You can send your participation keys to any malicious party with a
>> nice website (see random example [2]) offering you a good return.
>> Damn it's still Proof-of-SquareSpace!
>>
>> I believe we are talking about a comparison to PoW, correct? If you
>> want to mine PoW, you need to buy expensive hardware and configure
>> it to work, and wait a long time to get any return by solo mining.
>> Or you can join a mining pool, which might use your hashing power
>> for nefarious purposes. Or you might skip the hardware all together
>> and fall for some "cloud mining" scheme with a pretty website and a
>> high rate of advertised return. So as you can see,
>> Proof-of-SquareSpace exists in PoW as well!
>>
>> The PoS equivalent of buying mining hardware is setting up your own
>> validator and not outsourcing that to anyone else. So both PoW and
>> PoS have the professional/expert way of participating, and the
>> fraud-prone, amateur way of participating. The only difference is,
>> with PoS the professional/expert way is accessible to anyone with a
>> raspberry Pi and a web connection, which is a much lower barrier to
>> entry than PoW. _______________________________________________
>> 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
> _______________________________________________
> 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

📅 Original date posted:2021-05-17 📝 Original message:This ...

2023-06-07T22:53:32Z

In reply to nevent1q…sz3a
_________________________

📅 Original date posted:2021-05-17
📝 Original message:This is silly, but I'll add my take:

This would create the incentive to have chips that are idle 50% of the
time and work harder 50% of the time. This means miners would buy twice
the chips to use the same amount of power, for example.

This in turn means a greater portion of your operational costs are spent
on chips, and a smaller portion on electricity, reducing the incentive
to use cheaper power and turn off when it's expensive, because you need
to recoup your investment. That seems like a bad thing.

Here's my proposal: if you want a PoW algorithm that's better for the
environment, make one where the chips are easier to manufacture, so
power costs become a greater portion of miner expenditures. Maybe
SIMON/SPECK would do it. It could also incentivize someone to find that
NSA backdoor...

On 2021-05-14 21:41, Michael Fuhrmann via bitcoin-dev wrote:
> Hello,
>
> Bitcoin should create blocks every 10 minutes in average. So why do
> miners need to mine the 9 minutes after the last block was found? It's
> not necessary.
>
> Problem: How to prevent "pre-mining" in the 9 minutes time window?
>
> Possible ideas for discussion:
>
> - (maybe most difficult) global network timer sending a salted hash
> time
> code after 9 minutes. this enables validation by nodes.
>
> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> high enough) times higher difficulty. so everyone can mine any time but
> before to 9 minutes are up there will be a too high downside. It is
> more
> efficient to wait then paying high bills. The bitcoin will get a
> "puls".
>
>
> I dont think I see all problems behind these ideas but if there is a
> working solution to do so then the energy fud will find it's end.
> Saving
> energy without loosing rosbustness.
>
>
>
> :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-05-08 📝 Original message:Why ...

2023-06-07T22:52:29Z

In reply to nevent1q…6cjt
_________________________

📅 Original date posted:2021-05-08
📝 Original message:Why the existing mnemonic? If you've already dealt with unencrypted
material carelessly, the genie is out of the bottle. And if you're OK
with making a new one, why not just use BIP-39 passphrases to begin
with?

If you must, it seems like a decent way to accomplish it, but raw
SHA-256 is probably not the best choice. PBKDF2 like in the BIP-39 spec
is tried and true, or something like scrypt. This would however change
the storage format - you'd have to store a salt too, making your
mnemonic bigger.

On 2021-05-05 17:32, Tobias Kaupat via bitcoin-dev wrote:
> Hi all,
> I want to start a discussion about a use case I have and a possible
> solution. I have not found any satisfying solution to this use case
> yet.
>
> Use case:
> An existing mnemonic (e.g. for a hardware wallet) should be saved on a
> paper backup in a password encrypted form. The encrypted form should
> be a mnemonic itself to keep all backup properties like error
> correction.
>
> Suggested solution:
> 1) Take the existing mnemonic and extract the related entropy
> 2) Create a SHA526 hash (key) from a user defined password
> 3) Use the key as input for an AES CTR (empty IV) to encrypt the
> entropy
> 4) Derive a new mnemonic from the encrypted entropy to be stored on a
> paper backup
>
> We can add some hints to the paper backp that the mnemonic is
> encrypted, or prefix it with "*" to make clear it's not usable without
> applying the password via the algorithm above.
>
> To restore the original mnemonic, one must know the password and need
> to follow the process above again.
>
> An example implementation in GoLang can be found here:
> https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go
>
> Why not use the existing BIP-39 Passphrase?
> When generating a mnemonic with passphrase, the entropy is derived
> from the passphrase. When you have an existing mnemonic without a
> passphrase, any attempt to add a passphrase will end up in a different
> seed and thus a different private key. What we actually need is to
> encrypt the entropy.
>
> I'm open for your feedback. All encryption parameters are up to
> discussion and the whole proposal needs a security review. It's just
> the first draft.
>
> Existing solutions
> One solution I found is "Seedshift" which can be found here:
> https://github.com/mifunetoshiro/Seedshift
>
> But I consider it less secure and I would like to suggest a solution
> based on provably secure algorithms rather than a "rot23 derivation".
> Also using a date as password seems not very clever to me.
>
> Kind regards
> Tobias
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-04-22 📝 Original message:You ...

2023-06-07T22:52:00Z

In reply to nevent1q…9zfm
_________________________

📅 Original date posted:2021-04-22
📝 Original message:You appear to have reinvented Namecoin ;)

On 2021-04-21 20:28, Christopher Gilliard via bitcoin-dev wrote:
> I have created an additional BIP that is associated with the recent
> BIPs that I have sent to the mailing list. This one defines a
> decentralized naming protocol. The BIP can be found
> here:https://github.com/cgilliard/bips/blob/naming/bip-XXXX.mediawiki
>
> Please reply with any feedback, questions, or comments.
>
> Regards,
> Chris
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-04-19 📝 Original ...

2023-06-07T22:51:54Z

In reply to nevent1q…0gt3
_________________________

📅 Original date posted:2021-04-19
📝 Original message:Bitcoin presently suffers from unconstrained UTXO set growth. It would
be possible to disincentivize this and incentivize consolidating UTXOs
by adding a block weight penalty for UTXO creation, and bonus for UTXO
destruction:

* For each block, calculate the net change in UTXOs. If all the
transactions in a block consume 6,256 inputs and create 6,512 outputs,
the net change is +256.
* For each block, change the weight limit by -penalty * delta
* For example, if the penalty is 10 vB/UTXO, that block would be 10*256
= 2560 vB smaller. At a fee of 150 sat/vB, this would reduce the
potential transaction fees by 0.00384000 BTC ($230 at current prices)

(Alternatively, it would also be possible to make the penalty in coin,
which would require miners to fail to claim/burn an equivalent amount of
subsidy.)

A problem is that it is not possible to increase the weight limit (or
the block reward). I can see three possible solutions to this:

1) Let any excess be wasted. Miners can only use consolidated UTXOs to
offset new ones.
2) Decrease the weight limit slightly (i.e. by 1%), so that miners have
an incentive to consolidate UTXOs at least up to that limit.
3) Increase the weight limit, but only if miners consolidate enough
UTXOs.

Aside from the obvious issues with the third option (it would be a
hardfork), another problem is that this would make it harder for low-fee
transactions to get confirmed; on blocks with bad fees, miners might
instead opt to create a load of dust UTXOs, so they can destroy them on
blocks with very high fees to free up capacity. On the other hand, this
might be seen as a feature rather than a bug, since it would allow block
sizes to vary by demand, a bit like VBR vs. CBR in audio compression.

Thoughts? Has this been discussed before?

📅 Original date posted:2021-04-19 📝 Original message:This ...

2023-06-07T22:51:50Z

In reply to nevent1q…0dv2
_________________________

📅 Original date posted:2021-04-19
📝 Original message:This has already been discussed and proposed in various papers and
articles, typically to replace SHA-256d with something else. It
basically works, but there's a some tiny issues:

1) Who goes first?

If you first calculate the expensive PoW and then do a cheap SHA-256d
around it, anyone can malleate it by changing the outer PoW.

If you first calculate the cheap SHA-256d and then do an expensive PoW
around it, it would work, but then you would have to retool the P2P
protocol.

2) What's the incentive for miners?

In a "normal" soft-fork, miners have the incentive to upgrade because
their blocks will be orphaned if they don't, and even the old clients
won't accept them.

Here, miners will be able to produce an alternate chain that will appear
valid to old clients, and that the new miners won't be able to orphan
(since their hash power is much weaker).

📅 Original date posted:2021-04-19 📝 Original message:> ...

2023-06-07T22:51:49Z

In reply to nevent1q…2uz9
_________________________

📅 Original date posted:2021-04-19
📝 Original message:> If only one hash is allowed per block, then those who wish to utilize
> the hash will have to out-bid each other ("fee-bidding"). This hash can
> then be used to create another chain ("merged-mining")

Merged mining at present only needs one hash for a merkle root, and
that's stored in the coinbase. It would be even simpler to add the
following rules:

1) No OP_RETURN transactions allowed at all
2) If you want to commit data, do so in that one transaction in the
coinbase

Also curious about how you'd handle the payment - do I need to put in a
transaction that burns bitcoins for the tx fee? That isn't free in terms
of storage either.

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

2023-06-07T18:29:56Z

In reply to nevent1q…al48
_________________________

📅 Original date posted:2021-03-03
📝 Original message:On 2021-03-03 20:48, Chris Belcher wrote:
> On 03/03/2021 17:30, yanmaani at cock.li wrote:
>> Is that supposed to be a good thing? "We should do X because it'll
>> work"
>> doesn't prove X is actually good. These things can be evil, but they
>> can
>> also be legitimate opposition to a change. Taking away the power of a
>> "social media blitz" is not guaranteed to be a good thing!
> It is good that social media drama can only make its own followers fork
> away. In bitcoin people represent themselves, if they want certain
> rules
> enforced they should have to actually tell their software to do that.
> The problem with BIP8 is that social media drama has a incentive to
> promote brinksmanship.

Tell their software to do it, yes, but fork it? That seems like a big
"I'm sorry Dave, I'm afraid I can't do that" moment. If I tell Bitcoin
Core to do something, it seems like a bad thing that it would favor the
Core devs' wishes ("Get Taproot done") over mine.

>> That will only work for really egregious changes. In practice, most
>> people will trust Core on all other (non-egregious) decisions, because
>> of the inertia inherent in disobeying them.
[...]
>> You're right in suggesting that it will work, but the reason why it
>> will
>> work is because nobody wants to disobey Core. It seems immoral to
>> exploit this fact.

> It is not correct to say that this will work because "nobody will
> disobey Core". In reality it will work because basically everyone
> either
> wants taproot or has no opinion about taproot.

Both can be true at the same time. This is going to work because
basically nobody opposes Taproot. But if you did have some people
opposing Taproot, it would still work, because nobody would want to
disobey Core.

> Your argument depends heavily on the word "egregious". I've shown that
> for harmful changes like censorship can be resisted by the bitcoin
> community. Can you come up with an example of a bad change which won't
> be resisted?

Example 1: There is currently a specific mining pool planning to
blacklist addresses on sanctions lists. If they were to
convince/bribe/threaten Core to soft-fork so as to burn one specific
UTXO worth $1, the only direct victim of that would be the holder of
that UTXO, who loses only $1 from it.

Example 2: A soft fork to decrease the block size by 0.1%.

If we assume that the current block size is optimal and censorship is
bad, it seems simultaneously true that
1) it would be bad to decrease the block size or to burn that UTXO
2) nobody would be wiling to fight a war over a 0.1% decrease or a $1
loss to one guy

You might say that these are minor changes. Sure. But that's what I'm
saying: if the change is big ("egregious") enough to seriously
inconvenience people, they would fight it, but if it's trivial (thought
still bad), the inertia of Core would force them to accept it.

> Here's another example of an easily-resisted change: A Core team that's
> been compromised might do a flag-day UASF where transactions are only
> confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
> community could resist this by doing a counter-UASF where a transaction
> paying just 1 sat/vbyte is required to be included in the first block
> after the flay day.

(Nitpick: Miners would probably not support it, because less people
would be willing to pay that fee.)

Sure, and this change would be resisted because it seriously
inconveniences people. But what if it's just 2sat/vbyte?

>> At least you shouldn't hard-code it and require dissenters to fork
>> away.
>> I exhort you to consider making all this controversial stuff settings
>> that can be changed by RPC command or command-line flag; set the
>> default
>> value sure, but requiring a fork to change it is, in my opinion,
>> oppressive.
> What alternative do you suggest? If you advocate allowing miners to
> activate soft forks then that still won't protect users. Because miners
> won't save users in my above example of a 1000 sat/vbyte price floor,
> in
> fact miners would see their income greatly increased if the soft fork
> was successful. So in fact the ability to do a counter-UASF is always
> what actually protected users, miner protection is nothing something to
> count on.

I don't disagree. The ability to do a counter-UASF should also be added,
if it's envisioned somebody might want to do that.

Basically, I think that Core should provide users with the tools to
express their views and to exercise their economic power, and they could
give them default values according to what they think best.

However, they shouldn't force people to use a forked client if they want
to disobey them. That would be to abuse the power vested in the
development group.

>> On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
>>> Enter flag day activation. With a flag day there can be no
>>> brinksmanship. A social media blitz cant do anything except have its
>>> own
>>> followers fork away. Crucially, miner signalling cant be used to
>>> change
>>> the activation date for nodes that didn't choose to and just
>>> passively
>>> follow signalling. Changing the activation date requires all those
>>> users
>>> to actually run different node software.
>>
>>
>>> What if one day the Core developer team uses the flag
>>> day method to do something bad? The bitcoin user
>>> community who wants to resist this can create their own
>>> counter-soft-fork full node. This forces a chain
>>> split. The real bitcoin which most people follow will be
>>> the chain without censorship.
>>
>> [edited for brevity]
>>
>>
>> What you suggest may be an efficient way to ram taproot through, but
>> is
>> it inherently good? Nothing is free. This seems like de-facto forcing
>> people to go along with you, because you're convinced you're right. In
>> this case, you are, but you'd be convinced you'd be right even if you
>> weren't so.
>>

>>

>>
>> (Also consider some compromise, such as ">95% miner support before
>> flag
>> day or >33% on flag day")
>>
>> Best wishes
>> Yanmaani

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

2023-06-07T18:29:55Z

In reply to nevent1q…pmzn
_________________________

📅 Original date posted:2021-03-03
📝 Original message:On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
> Enter flag day activation. With a flag day there can be no
> brinksmanship. A social media blitz cant do anything except have its
> own
> followers fork away. Crucially, miner signalling cant be used to change
> the activation date for nodes that didn't choose to and just passively
> follow signalling. Changing the activation date requires all those
> users
> to actually run different node software.

Is that supposed to be a good thing? "We should do X because it'll work"
doesn't prove X is actually good. These things can be evil, but they can
also be legitimate opposition to a change. Taking away the power of a
"social media blitz" is not guaranteed to be a good thing!

> What if one day the Core developer team uses the flag
> day method to do something bad? The bitcoin user
> community who wants to resist this can create their own
> counter-soft-fork full node. This forces a chain
> split. The real bitcoin which most people follow will be
> the chain without censorship.

[edited for brevity]

That will only work for really egregious changes. In practice, most
people will trust Core on all other (non-egregious) decisions, because
of the inertia inherent in disobeying them.

What you suggest may be an efficient way to ram taproot through, but is
it inherently good? Nothing is free. This seems like de-facto forcing
people to go along with you, because you're convinced you're right. In
this case, you are, but you'd be convinced you'd be right even if you
weren't so.

You're right in suggesting that it will work, but the reason why it will
work is because nobody wants to disobey Core. It seems immoral to
exploit this fact.

At least you shouldn't hard-code it and require dissenters to fork away.
I exhort you to consider making all this controversial stuff settings
that can be changed by RPC command or command-line flag; set the default
value sure, but requiring a fork to change it is, in my opinion,
oppressive.

(Also consider some compromise, such as ">95% miner support before flag
day or >33% on flag day")

Best wishes
Yanmaani

📅 Original date posted:2021-03-03 📝 Original message:No, ...

2023-06-07T18:29:43Z

In reply to nevent1q…cl8e
_________________________

📅 Original date posted:2021-03-03
📝 Original message:No, it's not the same. This approach is not guaranteed to activate. On
flag day, it'd check for (say) 20% miner support, and activate if so. If
>80% of miners oppose, it'd fail. LOT=true (and declining percentage) will activate unconditionally.

Also, the day before lock-in, this would still have 95% as the limit,
not a linear interpolation between 95% and the lock-in limit.

This checks: if miner support > 95% support it (ever) or miner support >
X% (on flag day), activate
DP checks: if miner support > lerp(95%, 0%) (ever), activate
LOT=true checks: on flag day, activate unconditionally

(Erik: I forgot to hit reply all on my last e-mail, that's why you're
seeing this twice)

On 2021-03-02 06:11, Erik Aronesty wrote:
> This is the declining percentage of signaling activation.
>
> It has all the benefits of both.
>
> Eventually it becomes a LOT=true, so any argument for LOT=true holds
>
> And all of the arguments for LOT=false are satisfied by the cool down
> period.
>
> On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> How about a compromise?
>>
>> With LOT=false, taproot will be activated if at least 95% of the
>> miners
>> vote yes.
>> With LOT=true, taproot will be activated if at least 0% of the
>> miners
>> vote yes.
>> ...with LOT=maybe, taproot will be activated if at least ~some% of
>> the
>> miners vote yes?
>>
>> If you want the 'emergency cancel' feature without binding yourself
>> to
>> it, couldn't you have some middle-of-the-road solution? "Taproot
>> will be
>> enabled if miner support ever goes above 95%, or on flag day if
>> miner
>> support is >20% then". That would prevent obstreperous miners from
>> doing
>> too much damage, while still hopefully making it possible to bail
>> out of
>> a disaster.
>>
>> On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
>>> On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via
>> bitcoin-dev
>>> wrote:
>>>> As we saw in 2017 with BIP 9, coordinating activation by miner
>> signal
>>>> alone,
>>>> despite its potential benefits, also leaves open the door to a
>> miner
>>>> veto.
>>>
>>> To the contrary, we saw in 2017 that miners could *not*
>> successfully
>>> veto a BIP 9 activation. It was certainly more effort and risk
>> than was
>>> desirable to override the attempted veto, but the attempt at
>> vetoing
>>> nevertheless failed.
>>>
>>>> It wouldn't be much different than adding back the inflation bug
>>>> (CVE-2018-17144) and trusting miners not to exploit it.
>>>
>>> That is ridiculous FUD.
>>>
>>>> With LOT=False in the picture, however, things can get messy:
>>>
>>> LOT=false is always in the picture if we are talking about a
>> soft-fork:
>>> the defining feature of a soft-fork is that old node software
>> continues
>>> to work, and old node software will be entirely indifferent to
>> whether
>>> activation is signalled or not.
>>>
>>>> some users will
>>>> enforce Taproot(eg) (those running LOT=True), while others will
>> not
>>>> (those
>>>> with LOT=False)
>>>
>>> If you are following bip8 with lockinontimeout=false, you will
>> enforce
>>> taproot rules if activation occurs, you will simply not reject
>> blocks
>>> if
>>> activation does not occur.
>>>
>>>> Users with LOT=True will still get all the safety thereof,
>>>> but those with LOT=False will (in the event of miners deciding to
>>
>>>> produce a
>>>> chain split) face an unreliable chain, being replaced by the
>> LOT=True
>>>> chain
>>>> every time it overtakes the LOT=False chain in work.
>>>
>>> This assumes anyone mining the chain where taproot does not
>> activate is
>>> not able to avoid a reorg, despite having majority hashpower (as
>>> implied
>>> by the lot=true chain having to overtake them repeatedly). That's
>>> absurd;
>>> avoiding a reorg is trivially achieved via running
>> "invalidateblock",
>>> or
>>> via pool software examining block headers, or via a patch along
>> the
>>> lines
>>> of MUST_SIGNAL enforcement, but doing the opposite. For
>> concreteness,
>>> here's a sketch of such a patch:
>>>
>>>
>>
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
>>>
>>>> For 2 weeks, users with LOT=False would not have a usable
>> network.
>>>
>>> That's also ridiculous FUD.
>>>
>>> If it were true, it would mean the activation mechanism was not
>>> acceptable, as non-upgraded nodes would also not have a usable
>> network
>>> for the same reason.
>>>
>>> Fortunately, it's not true.
>>>
>>> More generally, if miners are willing to lose significant amounts
>> of
>>> money mining orphan blocks, they can do that at any time. If
>> they're
>>> not inclined to do so, it's incredibly straightforward for them to
>>
>>> avoid
>>> doing so, whatever a minority of other miners might do.
>>>
>>>> The overall risk is maximally reduced by LOT=True being the only
>>>> deployed
>>>> parameter, and any introduction of LOT=False only increases risk
>>>> probability
>>>> and severity.
>>>
>>> LOT=false is the default behaviour of everything single piece of
>> node
>>> software out there. That behaviour doesn't need to be introduced,
>> it's
>>> already universal.
>>>
>>> Cheers,
>>> aj
>>>
>>> _______________________________________________
>>> 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

📅 Original date posted:2021-03-01 📝 Original message:How ...

2023-06-07T18:29:42Z

In reply to nevent1q…4a9c
_________________________

📅 Original date posted:2021-03-01
📝 Original message:How about a compromise?

With LOT=false, taproot will be activated if at least 95% of the miners
vote yes.
With LOT=true, taproot will be activated if at least 0% of the miners
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of the
miners vote yes?

If you want the 'emergency cancel' feature without binding yourself to
it, couldn't you have some middle-of-the-road solution? "Taproot will be
enabled if miner support ever goes above 95%, or on flag day if miner
support is >20% then". That would prevent obstreperous miners from doing
too much damage, while still hopefully making it possible to bail out of
a disaster.

On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
> On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev
> wrote:
>> As we saw in 2017 with BIP 9, coordinating activation by miner signal
>> alone,
>> despite its potential benefits, also leaves open the door to a miner
>> veto.
>
> To the contrary, we saw in 2017 that miners could *not* successfully
> veto a BIP 9 activation. It was certainly more effort and risk than was
> desirable to override the attempted veto, but the attempt at vetoing
> nevertheless failed.
>
>> It wouldn't be much different than adding back the inflation bug
>> (CVE-2018-17144) and trusting miners not to exploit it.
>
> That is ridiculous FUD.
>
>> With LOT=False in the picture, however, things can get messy:
>
> LOT=false is always in the picture if we are talking about a soft-fork:
> the defining feature of a soft-fork is that old node software continues
> to work, and old node software will be entirely indifferent to whether
> activation is signalled or not.
>
>> some users will
>> enforce Taproot(eg) (those running LOT=True), while others will not
>> (those
>> with LOT=False)
>
> If you are following bip8 with lockinontimeout=false, you will enforce
> taproot rules if activation occurs, you will simply not reject blocks
> if
> activation does not occur.
>
>> Users with LOT=True will still get all the safety thereof,
>> but those with LOT=False will (in the event of miners deciding to
>> produce a
>> chain split) face an unreliable chain, being replaced by the LOT=True
>> chain
>> every time it overtakes the LOT=False chain in work.
>
> This assumes anyone mining the chain where taproot does not activate is
> not able to avoid a reorg, despite having majority hashpower (as
> implied
> by the lot=true chain having to overtake them repeatedly). That's
> absurd;
> avoiding a reorg is trivially achieved via running "invalidateblock",
> or
> via pool software examining block headers, or via a patch along the
> lines
> of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> here's a sketch of such a patch:
>
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
>
>> For 2 weeks, users with LOT=False would not have a usable network.
>
> That's also ridiculous FUD.
>
> If it were true, it would mean the activation mechanism was not
> acceptable, as non-upgraded nodes would also not have a usable network
> for the same reason.
>
> Fortunately, it's not true.
>
> More generally, if miners are willing to lose significant amounts of
> money mining orphan blocks, they can do that at any time. If they're
> not inclined to do so, it's incredibly straightforward for them to
> avoid
> doing so, whatever a minority of other miners might do.
>
>> The overall risk is maximally reduced by LOT=True being the only
>> deployed
>> parameter, and any introduction of LOT=False only increases risk
>> probability
>> and severity.
>
> LOT=false is the default behaviour of everything single piece of node
> software out there. That behaviour doesn't need to be introduced, it's
> already universal.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2020-12-06 📝 Original message:The ...

2023-06-07T18:27:42Z

In reply to nevent1q…2gwe
_________________________

📅 Original date posted:2020-12-06
📝 Original message:The reason Samourai did not propose a BIP is that that was not a
proposal to improve the Bitcoin protocol.

You could write a specification for it, but this mailing list is
probably the wrong venue.

On 2020-12-06 18:20, Prayank via bitcoin-dev wrote:
> Hello Everyone,
>
> I know there have been lot of controversial and heated discussions
> involving Samourai in past. Ignoring everything including the tweets
> in which Samourai team mentioned no interest in proposing a BIP
> related to automated and secure communication used in Soroban, I
> wanted to know if enough people would be interested in a BIP because
> it may help other bitcoin projects in future.
>
> Tweets: https://twitter.com/SamouraiWallet/status/1334977957157367810
> [1]
>
> https://twitter.com/SamouraiDev/status/1335103101188104194 [2]
>
> Ben also tweeted that a BIP would make sense:
> https://twitter.com/benthecarman/status/1334977096079306753 [3]
>
> I think we should keep all the controversial things aside and do
> everything that helps Bitcoin. It's mentioned in the medium article
> that it can help other projects like joinmarket, coinswap, snickr etc.
>
> https://link.medium.com/uBvIJUSLQbb
>
> The source code for a client library in Java is available here
> https://code.samourai.io/wallet/soroban-client-java and the source
> code for the Go based server component is available here
> https://code.samourai.io/wallet/samourai-soroban
>
> Let me know if a BIP for such implementation to be used by other
> bitcoin projects makes sense and if anyone willing to help me in
> creating a BIP.
>
> Thanks.
>
> -- Prayank
>
> Links:
> ------
> [1] https://twitter.com/SamouraiWallet/status/1334977957157367810?s=19
> [2] https://twitter.com/SamouraiDev/status/1335103101188104194?s=19
> [3] https://twitter.com/benthecarman/status/1334977096079306753?s=19
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2020-11-24 📝 Original message:On ...

2023-06-07T18:27:35Z

In reply to nevent1q…wmjp
_________________________

📅 Original date posted:2020-11-24
📝 Original message:On 2020-11-23 12:24, AdamISZ via bitcoin-dev wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Canvassing opinions/critiques from those working on bitcoin and
>> related protocols.
>>
>> See the attached gist for a write-up of an outline of an idea, which
>> is conceived for joinmarket but can apply in other scenarios where
>> there is market for liquidity and in which privacy is a very high
>> priority (hence 'bitcoin fungibility markets' can certainly include
>> coinswap along with coinjoin, but possibly other things):
>>
>> https://gist.github.com/AdamISZ/b52704905cdd914ec9dac9fc52b621d6
>
> Greg Maxwell pointed out to me on IRC that this idea doesn't work:
> there is only a receipt on the commitment to the offer (message) from
> the maker, not on the plaintext version, hence there is nothing
> stopping the maker from falsely claiming censorship after not sending
> the plaintext.
>
> Reflecting on this a bit more, my intuition is that this problem is
> much more difficult than I had hoped; if there is a solution I suspect
> it involves much more sophisticated ideas. Many solutions just end up
> begging the question by presuming the existence of an uncensorable BB
> in order to create a new one; and/or use the blockchain for that
> function, but that is too slow and expensive, usually. I'd be happy to
> be proved wrong, though :)
>
> waxwing
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Blockchains are bad for this, because you don't want for it to cost
money to use your bulletin board. However, the problem was solved more
than a decade ago. Look into FMS, which combines Usenet/mailing lists
with a web of trust for spam resistance.

📅 Original date posted:2020-09-19 📝 Original ...

2023-06-07T18:27:02Z

In reply to nevent1q…jlw4
_________________________

📅 Original date posted:2020-09-19
📝 Original message:Currently, Bitcoin's timestamp rules are as follows:

1. The block timestamp may not be lower than the median of the last 11
blocks'
2. The block timestamp may not be greater than the current time plus two
hours
3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
06:28:16 +0000)

Thus, Bitcoin will "die" on or about 2106-02-07, when there is no
timestamp below 2^32 that exceeds the median of the last 11 blocks.

If the rules were changed to the following, this problem would be
solved:

1. The block timestamp plus k*2^32 may not be lower than the median of
the last 11 blocks'
2. The block timestamp plus k*2^32 may not be greater than the current
time plus two hours
3. k is an integer, whose value must be the same for the calculations of
Rule 1 and Rule 2

This would cause a hardfork in the year 2106, which is approximately
85.5 years from now, by which time 95% of nodes would hopefully have
updated.

Another proposed solution is 64-bit timestamps. They would break
compatibility with other software that has specific expectations of
header fields, like ASICs' firmware. They would also cause a hardfork
before the date of timestamp overflow. I thus believe them to be a less
appropriate solution.

What do you think of this idea? Is it worth a BIP?