Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0
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 both say block is valid -> valid 2. Bitcoin Core and both say block is invalid -> invalid 3. Bitcoin Core says valid, says invalid -> valid (or get forked off) 4. Bitcoin Core says invalid, 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] death to the mempool, long live the mempool
[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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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, vju...@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 0xbadc0ded, invalid in 0x0001, and valid again in 0x0001badc0ded, 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 0x0001 all off-chain transactions with timelocks around 0x 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). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 Date2020-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 +) 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 0x 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Opinion on proof of stake in future
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
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
> 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
>> 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
Re: [bitcoin-dev] Opinion on proof of stake in future
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
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
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
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
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Decentralized Naming Protocol BIP
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-.mediawiki Please reply with any feedback, questions, or comments. Regards, Chris ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
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). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Block weight penalty for UTXO set growth
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? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
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 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 +, 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ b
Re: [bitcoin-dev] Making the case for flag day activation of taproot
On 2021-03-03 20:48, Chris Belcher wrote:
On 03/03/2021 17:30, yanma...@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
Re: [bitcoin-dev] Making the case for flag day activation of taproot
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
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 +, 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP - Automated and Secure Communication
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bulletin boards without selective censorability for bitcoin fungibility markets
On 2020-11-23 12:24, AdamISZ via bitcoin-dev wrote: ‐‐‐ Original Message ‐‐‐ On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev 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@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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
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 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 on behalf of Mike Brooks via bitcoin-dev Sent: Friday, 25 September 2020 5:40 AM To: bitcoin-dev 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
[bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32
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 +) 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? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
