yanmaani at cock.li [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-09-19 to 2022-02-13
💬 Posted a total of 23 messages
📚 Participated in the following categories: bitcoin-dev, Bitcoin Advent Calendar
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29

Profile Code

nprofile1qqsg7k70nw3dazxasaaxwtmznfwx57lthmdrlfgny3fpuqux8k87p9qw84jrr

Author Public Key

npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29

Show more details

Last Notes

2023-06-07 23:03:54

- reply

📅 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.

2023-06-07 23:01:27

- reply

📅 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.

2023-06-07 23:00:30

- reply

📅 Original date posted:2021-11-05
📝 Original message:On 2021-11-05 08:17, Prayank via bitcoin-dev wrote:
> What followed it (whitepaper being shared on different websites) was
> true decentralization and we need something similar in other aspects
> of full node implementations. Few things that can improve
> decentralization:
>
> 1.More people using alternative full node implementations. Right now
> 98% of nodes use Bitcoin Core.
Unfortunately, this isn't really possible. If they did that, you could
get consensus splits. This is why all the other stuff is so important -
if Bitcoin is subverted via soft-fork, you *can't* just run your own
fork.
Theoretically, I suppose you could run two implementations and do
something if they differ, but what?
1. Bitcoin Core and <AltImpl> both say block is valid -> valid
2. Bitcoin Core and <AltImpl> both say block is invalid -> invalid
3. Bitcoin Core says valid, <AltImpl> says invalid -> valid (or get
forked off)
4. Bitcoin Core says invalid, <AltImpl> says valid -> invalid (or
hardfork)
> 2.More people like Luke Dashjr and Amir Taaki who do not simp for
> anyone. Being a contributor or maintainer in Bitcoin full node
> implementation is different from other open source projects. It was
> never going to be easy and it will get difficult with time,
This is all about the money - it's easy to have people be independent
when their source of money is independent. But nobody's crazy enough to
bite the hand that feeds them, and you couldn't really build a system on
that basis. Our best hope is gentle hands, or contributors wealthy
enough not to have to care.
(Whatever happened to Amir Taaki, by the way?)
> 3.More people from different countries getting involved in important
> roles.
Isn't Bitcoin already plenty distributed? Funding people in
under-represented countries seems to me like a textbook exercise in
'box-ticking, but moreover, I'd frankly rather have reasonably well-off
guys from Western Europe/America who have the financial backbone to not
worry that much about attacks to their funding, than mercenaries who
have to follow orders or get fired. Even if they're from West
Uzbekistan.
(Maybe they need a union?)
> 4.Few anons.
Gonna guess you mean "a few anons," not fewer anons.
Again, problem is money. These days, nobody threatens anyone with
anything substantive, like murder - the threats all involve cutting off
some funding. So having anonymous people being funded by non-robust
sources doesn't really buy you that much, because the weakest link will
pretty much never be the de-jure, legal freedom of an individual.
Having a system that allows people to fund anonymous people better would
be interesting, but it has some challenges with trust and so on.
> 5.Individuals and organizations who fund different Bitcoin projects
> should consider contributing in alternative. full node implementations
> as well. Maybe start with Bitcoin Knots.
See above. Bitcoin Knots isn't really independent. btcd in Go is, so I
guess they could try that. But at the end of the day, it wouldn't help -
btcd has to be bug-for-bug compatible with Core, and it couldn't really
be any other way.
For my $0.05, what's needed is more "hard money" - if people could make
donations into a fund, with the fund then paying out to developers, and
that fund be controlled in a civilized and non-centralized way (that's
the hard part!), this would somewhat insulate developers from people
threatening to stop their contributions to The Fund, at the price of
having developers being able to be coerced by The Fund.
You could also look into a system like Monero's CCS. But at the end of
the day, funding is really a very difficult problem, no matter how you
slice it. The money still has to enter the system somehow. Since Bitcoin
is a public good, you can't really capture its value, and this means
individuals who can (e.g. by malicious activity) will always have the
leg up.

2023-06-07 23:00:23

- reply

📅 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

2023-06-07 23:00:09

- reply

📅 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

2023-06-07 23:00:09

- reply

📅 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).

2023-06-07 23:00:07

- reply

📅 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

2023-06-07 22:54:20

- reply

📅 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

2023-06-07 22:54:18

- reply

📅 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

2023-06-07 22:53:32

- reply

📅 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

2023-06-07 22:52:29

- reply

📅 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

2023-06-07 22:52:00

- reply

📅 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

2023-06-07 22:51:54

- reply

📅 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?

2023-06-07 22:51:50

- reply

📅 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).

2023-06-07 22:51:49

- reply

📅 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.

2023-06-07 18:29:56

- reply

📅 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

2023-06-07 18:29:55

- reply

📅 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

2023-06-07 18:29:43

- reply

📅 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

2023-06-07 18:29:42

- reply

📅 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

2023-06-07 18:27:42

- reply

📅 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

2023-06-07 18:27:35

- reply

📅 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.

2023-06-07 18:27:13

- reply

📅 Original date posted:2020-10-15
📝 Original message:What if a miner mines a block that has a very high block reward (i.e.
confirmed a juicy transaction), while at the same time having a floating
point fitness very close to the minimum?
For the sake of argument, let's say the block reward is 6.50 (4% more
than average), the fitness is 1.001, and the orphan rate is 0.3%.
With Nakamoto consensus, the miners would (allegedly) find it in their
best interest to work on that block, since it was first. It's a problem
when they don't, but the system basically works right now.
With FPNC, the miners have two equally valid options:
1) Attempt to create a block building on top of that block (reward:
6.25)
2) Attempt to replace (reward: 6.50)
If they do (1), their probability of success given a matching hash is
(100 - orphan rate)%, which is very close to 100%.
If they do the second, their probability of success given a hit is (100
- percentile(1.001)), which also is very close to 100%.
Option 1 has EV of .997 * 1 * 6.25 = 6.25.
Option 2 has EV of (1 - quantile(1.001)) * 1.04 * 6.25, which is surely
above 6.25. I don't know how to calculate the quantile, but it's
obvious.
With the block subsidy getting lower and lower as time goes on, the
probability of this happening goes up.
Don't we want miners to always keep the chain going forward? Your
proposal incentivizes reorgs.
On 2020-10-10 01:26, Mike Brooks via bitcoin-dev wrote:
> James,
>
> FPNC and NC will always select the highest-work chain, I am suggesting
> that by adding more bits of precision we avoid confusion.
>
> Part 2 -> Using a genetic algorithm that passes fitness with heredity
> to resolve disagreements has never been introduced to this mailing
> list. This hard-nack is null and void.
>
> Best Regards,
> Michael
>
> On Tue, Sep 29, 2020 at 12:30 AM LORD HIS EXCELLENCY JAMES HRMH via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good Afternoon,
>>
>> Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
>>
>> I note that the discussion thread for this proposal has previously
>> received HARD_NAK
>>
>> I note in the whitepaper the following basic introduction of need:
>>
>>> As a result anode will simply adopt the first solution seen,
>> creating a kind of race condition.
>>
>> The said race condition, it is not noted, is 'self-resolving' with
>> the network adopting the longest chain with the highest proof of
>> work as any contentious tip is built on. This is the proper reason
>> for waiting for two confirmations for a transaction as a minimum
>> proof of its inclusion in the blockchain (without fraud), and for
>> waiting for six confirmations before considering that a transaction
>> is 'final'.
>>
>> I take it that your work is intended to allow the network to decide
>> immediately without waiting for a chain to be further extended, in
>> that case, the solution should be as noted elsewhere to accept the
>> higher proof of work with the greater precision proof. When
>> comparing two competing blocks there is an indirect reference to a
>> higher proof of work due to the greater precision in the block hash,
>> although the answer could have been arrived with fewer attempts. As
>> it is, the total proof of work is not directly calculated but is
>> evaluated as the chain with more blocks being the chain with more
>> proof-of-work, whereas in the cases two blocks are received as
>> alternates extending the same chain tip there is currently no method
>> of comparison to determine which of the blocks, and the correct tip
>> is not chosen without further proof-of-work to extend a tip.
>> Resolving this reduces the network expense of reorganisation in
>> ordinary conditions but in the case of a network-split resolves
>> nothing.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>> Willtech
>> www.willtech.com.au [1]
>> www.go-overt.com [2]
>> and other projects
>>
>> earn.com/willtech [3]
>> linkedin.com/in/damianwilliamson [4]
>>
>> m. 0487135719
>> f. 61261470192
>>
>> ----
>>
>> -------------------------
>>
>> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
>> behalf of Mike Brooks via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Sent: Friday, 25 September 2020 5:40 AM
>> To: bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Floating-Point Nakamoto Consensus
>>
>> Hey Everyone,
>>
>> A lot of work has gone into this paper, and the current revision
>> has been well received and there is a lot of excitement on this side
>> to be sharing it with you today. There are so few people that truly
>> understand this topic, but we are all pulling in the same direction
>> to make Bitcoin better and it shows. It is wildly underrated that
>> future proofing was never really a consideration in the initial
>> design - but here we are a decade later with amazing solutions like
>> SegWit which gives us a real future-proofing framework. The fact
>> that future-proofing was added to Bitcoin with a softfork gives me
>> goosebumps. I'd just like to take the time to thank the people who
>> worked on SegWit and it is an appreciation that comes up in
>> conversation of how difficult and necessary that process was, and
>> this appreciation may not be vocalized to the great people who
>> worked on it. The fact that Bitcoin keeps improving and is able to
>> respond to new threats is nothing short of amazing - thank you
>> everyone for a great project.
>>
>> This current proposal really has nothing to do with SegWit - but it
>> is an update that will make the network a little better for the
>> future, and we hope you enjoy the paper.
>>
>> PDF:...
>> CONCLUSION
>>
>> Floating-Point Nakamoto consensus allows the network to form a
>> consensus more quickly by avoiding ambiguity allowing for
>> determinism to take hold. Bitcoin has become an essential utility,
>> and attacks against our networks must be avoided and adapting,
>> patching and protecting the network is a constant effort. An
>> organized attack against a cryptocurrency network will undermine the
>> guarantees that blockchain developers are depending on.
>> Any blockchain using Nakamoto Consensus can be modified to use a
>> fitness constraint such as the one used by a Floating-Point Nakamoto
>> Consensus. An example implementation has been written and submitted
>> as a PR to the bitcoin core which is free to be adapted by other
>> networks.
>>
>> A complete implementation of Floating-Point Nakamoto consensus is in
>> the following pull request:
>>
>> https://github.com/bitcoin/bitcoin/pull/19665/files [5]
>> Paper:
>>
>> https://github.com/in-st/Floating-Point-Nakamoto-Consensus [6]
>>
>> https://in.st.capital [7]
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> Links:
> ------
> [1] http://www.willtech.com.au
> [2] http://www.go-overt.com
> [3] http://earn.com/willtech
> [4] http://linkedin.com/in/damianwilliamson
> [5] https://github.com/bitcoin/bitcoin/pull/19665/files
> [6] https://github.com/in-st/Floating-Point-Nakamoto-Consensus
> [7] https://in.st.capital/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:27:02

- reply

📅 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?