Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Good morning yanmaani, > It's well-known. Nobody really cares, because it's so far off. Not > possible to do by softfork, no. I think it is possible by softfork if we try hard enough? > 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 +) What happens if a series of blocks has a timestamp of 0x at the appropriate time? In that case: 1. Is not violated, since "not lower than" means "greater than or equal to", and after a while the median becomes 0x and 0x == 0x 2. Is not violated, since it would be a past actual real time. 3. Is not violated since 0x < 0x1. In that case, we could then add an additional rule, which is that a 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinbase transaction, with similar rules except translated to 64-bit/128-bit/256-bit. Possibly a similar scheme could be used for `nLockTime`; we could put a 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 if the legacy v`nLockTime` is at the maximum seconds-timelock possible. Regards, ZmnSCPxj ___ 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
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). On 2021-10-15 23:48:59 user yanma...@cock.li wrote: > 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] 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] Year 2038 problem and year 2106 chain halting
Making Bitcoin function after 2038 is by definition a hard fork I feel if we do HF, we should bundle other HF changes with it... On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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] Taproot testnet wallet
Hi Andreas, > I'm trying to finish off bitcoinj's implementation for sending to taproot addresses. For this, I'd like to test against a wallet that can receive to P2TR and spend back. I did this transaction few days back which creates a P2TR output while answering a question on Bitcoin Stackexchange: https://blockstream.info/testnet/tx/2035ead4a9d0c8e2da1184924abc9034d26f2a7093371183ef12891623b235d1 Pieter Wuille and Anthony Towns already shared things that would be helpful. Still wanted to share the steps I did for above transaction: https://bitcoin.stackexchange.com/a/108013/ TL;DR - 1.Create a blank descriptor wallet with private keys disabled 2.Import TPUB descriptor in wallet 3.Create new bech32m address 4.Send some bitcoin from another wallet The answer could be improved if test vectors are added in BIP 86 for TPRV for follow things suggested by Anthony Towns in last email. -- Prayank A3B1 E430 2298 178F ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taproot testnet wallet
On 2021-10-15 03:05:36 user Anthony Towns via bitcoin-dev wrote: > Same stuff works with testnet, though I'm not sure if any testnet faucets will accept bech32m addresses directly. There are faucets that accept such addresses, for example https://bitcoinfaucet.uo1.net/, but you have to use bech32 checksum instead of bech32m, for example sending to tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aqus27cytz works fine, but sending to tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aquslzggwq does not work. The same with pages like mempool.space, you have to use bech32 instead of bech32m, then you can send to taproot from some old faucets or browse taproot addresses from some old block explorers. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On the regularity of soft forks
Interesting discussion. Correct me if I'm wrong: but putting too many features together in one shot just can't make things harder to debug in production if something very unexpected happens. It's a basic principle of software engineering. Change. Deploy. Nothing bad happened? Change it a little more. Deployment. Or: Change, change, change. Deploy. Did something bad happen? What change caused the problem? On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote: > > > ... in this post I will argue against frequent soft forks with a > single or > > minimal > > > set of features and instead argue for infrequent soft forks with > batches > > > of features. > > I think this type of development has been discussed in the past and has > been > > rejected. > > > AJ: - improvements: changes might not make everyone better off, but we > >don't want changes to screw anyone over either -- pareto > >improvements in economics, "first, do no harm", etc. (if we get this > >right, there's no need to make compromises and bundle multiple > >flawed proposals so that everyone's an equal mix of happy and > >miserable) > > I don't think your conclusion above matches my opinion, for what it's > worth. > > If you've got two features, A and B, where the game theory is: > > If A happens, I'm +100, You're -50 > If B happens, I'm -50, You're +100 > > then even though A+B is +50, +50, then I do think the answer should > generally be "think harder and come up with better proposals" rather than > "implement A+B as a bundle that makes us both +50". > > _But_ if the two features are more like: > > If C happens, I'm +100, You're +/- 0 > If D happens, I'm +/- 0, You're +100 > > then I don't have a problem with bundling them together as a single > simultaneous activation of both C and D. > > Also, you can have situations where things are better together, > that is: > > If E happens, we're both at +100 > If F happens, we're both at +50 > If E+F both happen, we're both at +9000 > > In general, I think combining proposals when the combination is better > than the individual proposals were is obviously good; and combining > related proposals into a single activation can be good if it is easier > to think about the ideas as a set. > > It's only when you'd be rejecting the proposal on its own merits that > I think combining it with others is a bad idea in principle. > > For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx > and CHECKSIGADD together because they do have synergies like that; we > didn't bundle ANYPREVOUT and graftroot despite the potential synergies > because those features needed substantially more study. > > The nulldummy soft-fork (bip 147) was deployed concurrently with > the segwit soft-fork (bip 141, 143), but I don't think there was any > particular synergy or need for those things to be combined, it just > reduced the overhead of two sets of activation signalling to one. > > Note that the implementation code for nulldummy had already been merged > and were applied as relay policy well before activation parameters were > defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becoming > an active soft fork. > > 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
