Kate Salazar [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-10-16 to 2022-06-29
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:10:10

- reply

📅 Original date posted:2022-06-29
📝 Original message:Hey
On Tue, Jun 28, 2022 at 10:43 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> @Eric
> > People who transact are realizing the benefit of money - the avoidance
> of barter costs.
>
> I'm very confident you're incorrect that holders don't receive any benefit
> and you're certainly not correct that every spend is receiving the same
> benefit. As I'm sure you're aware, one of the primary components of a
> currency's value and purpose is as a store of value. Storing value happens
> while you're holding it, not while you're spending it. Consider the
> following two scenarios: one person holds onto 10 bitcoin for 10 years and
> then spends those 10 bitcoins in some way in 2 transactions. Another person
> spends 4 bitcoins to buy something, then sells it for 6 bitcoins, and then
> buys something else for that 6 bitcoins and then never acquires any bitcoin
> for 10 years.
>
> Both people spent 10 bitcoins over 2 transactions. Over that 10 year
> period, only one of those people utilized bitcoin's utility as a store of
> value. Who benefited more from their use of bitcoin?
>
> > Those who never transact, never realize any benefit.
>
> While that's true, its not relevant and basically a red herring. You need
> to compare those who transact often and rarely hold, to those who hold a
> lot but rarely transact. Its not helpful to consider those who throw their
> bitcoin into a bottomless pit and never retrieve them.
>
> On an idealistic level, I agree with Keagan that it would make sense to
> have "a balance of fees to that effect". I think doing that would be
> technically/economically optimal. However, I think there is an enormous
> benefit to having a cultural aversion to monetary inflation and the
> consequences of convincing the bitcoin community that inflation is ok could
> have unintended negative consequences (not to mention how difficult
> convincing the community would be in the first place). There's also the
> economic distortion that inflation causes that has a negative effect which
> should also be considered. The idea of decaying utxo value is interesting
> to consider, but it would not solve the economic distortion that
> monetary inflation causes, because that distortion is a result of monetary
> devaluation (which decaying utxos would be a form of). Then again, maybe in
> this case the distortion of inflation would actually be a correction -
> correcting for the externality of benefit received by holders. I'm
> stream-of-consciousnessing a bit, but anyways, I suspect its not worth the
> trouble to perfect the distribution of bitcoin blockchain security costs to
> include holders. Tho, if I were to go back in time and influence how
> bitcoin was designed, I might advocate for it.
>
Pool operators are free to request larger fees from older utxos, or from
all utxos, or from newer utxos, at their judgement, looking at the
blockspace demand census and at what the other pool operators are doing.
This is not consensus, it's policy. It's not a technology problem, it's
solved above in the social layer.
If this kind of problem torments anyone, maybe miner decentralization hard
forks are worth looking at, some already exist.
>
> @Peter
> > demurrage and inflation have identical economic properties.
>
> The distortion of incentives is identical, however there is also the
> effect it has on a currency's property as a useful unit of account.
> Decaying utxos would mean that it would contribute substantially less to
> market prices needing to change. I suspect this effect would be bordering
> on negligible tho.
>
> On Thu, Jun 23, 2022 at 2:17 PM Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tue, Jun 21, 2022 at 01:00:07PM -0600, Keagan McClelland via
>> bitcoin-dev wrote:
>> > > The PoW security of Bitcoin benefits all Bitcoin users, proportional
>> to
>> > the
>> > value of BTC they hold; if Bitcoin blocks aren't reliably created the
>> value
>> > of
>> > *all* BTC goes down. It doesn't make sense for the entire cost of that
>> > security
>> > to be paid for on a per-tx basis. And there's a high chance paying for
>> it
>> > on a
>> > per-tx basis won't work anyway due to lack of consistent demand.
>> >
>> > FWIW I prefer the demurrage route. Having something with finite supply
>> as a
>> > means of measuring economic activity is unprecedented and I believe
>> deeply
>> > important. I'm sympathetic to the argument that the security of the
>> chain
>> > should not be solely the responsibility of transactors. We realize the
>> > value of money on receipt, hold *and* spend and it would be appropriate
>> for
>> > there to be a balance of fees to that effect. While inflation may be
>> > simpler to implement (just chop off the last few halvings), I think it
>> > would be superior (on the assumption that such a hodl tax was
>> necessary) to
>> > keep the supply fixed and have people's utxo balances decay, at least at
>> > the level of the UX.
>>
>> Demurrage makes protocols like Lightning much more complex, and isn't
>> compatible with existing implementations. While demurrage could in theory
>> be
>> implemented in a soft-fork by forcing txs to contain an output with the
>> demurrage-taxed amount, spending to a pool of future mining fees, I really
>> don't think it's practical to actually do that.
>>
>> Anyway, demurrage and inflation have identical economic properties.
>> They're
>> both a tax on savings. The only difference is the way that tax is
>> implemented.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220629/0ba8c96a/attachment.html>

2023-06-07 23:10:06

- reply

📅 Original date posted:2022-06-19
📝 Original message:Hey
On Sun, Jun 19, 2022 at 8:04 PM Manuel Costa via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> "Long time listener, first time caller". Just sharing my 2 sats:
>
> While I find it stimulating, I think this discussion (and other similar
> doom-like scenarios) is somewhat irrelevant in practice.
>
> When the time comes and if we start seeing issues with block rewards being
> too low to maintain acceptable security, we're going to have multiple
> solutions being implemented for it, and definitely a hard fork to
> indefinitely maintain some degree of block subsidy is going to be within
> them.
> If it is indeed confirmed that the original chain is now insecure,
> consensus should eventually coalesce in one of the hard forks that can
> actually keep moving forward with some degree of security assurance.
>
> I feel like people sometimes think of these systems as when they fail
> there's a full loss, but that's not the case as the history is not lost,
> and so we can move forward from that history with multiple alternatives and
> allow the social/economic consensus to dictate which one becomes the new
> accepted chain.
> The genie is out of the box, and some chain whose history is prefixed by
> Bitcoin's current chain history will always exist.
>
I think you are right, the keywords maybe being consensus eventually
coalesces in the most viable chain.
> The only type of problems we should truly be worrying about are ones that
> might invalidate the security of the history itself, like a cryptographic
> breakthrough (quantum computing for example) that would turn some or all
> utxos into "anyone can spend".
>
I think this is wrong. An entity investing in quantum power and letting
their chop onto some particular utxos is a reasonable outcome. It parallels
a tangible scenario: gang somehow getting a bulldozer and driving it into
some particular safe. Being able to rewind such events is the only security
issue here.
More generally, circulating supply is circulating supply, to all effect,
outcome is desirable or not.
> Transitions might be disorderly and filled with drama and discussion as
> the "block size wars" in 2017, but anyone who doesn't want to "vote", can
> always just keep their utxos frozen in place while the drama sorts itself
> out, and maintain whatever holdings they previously had on the new accepted
> chain.
>
> Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> escreveu no dia domingo, 19/06/2022 à(s) 11:32:
>
>> On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote:
>> > Hi Peter,
>> >
>> > > Only because the block reward goes away. If it was made to continue
>> > > indefinitely - most likely with an inflation hard fork - demand for
>> block space
>> > > would not be critical to Bitcoin's security.
>> >
>> >
>> > I am not completely against your proposal although 100% sure this will
>> not have "consensus" to be implemented. I think if bitcoin doesn't have
>> enough demand for block space, it should die. I will be sad if bitcoin
>> doesn't exist but it should be a lesson for all the people opposing soft
>> forks based on drama and politics instead of technical review.
>> >
>> > I don't see anything wrong with users paying 100x fees for opening and
>> closing LN channels.
>>
>> The PoW security of Bitcoin benefits all Bitcoin users, proportional to
>> the
>> value of BTC they hold; if Bitcoin blocks aren't reliably created the
>> value of
>> *all* BTC goes down. It doesn't make sense for the entire cost of that
>> security
>> to be paid for on a per-tx basis. And there's a high chance paying for it
>> on a
>> per-tx basis won't work anyway due to lack of consistent demand.
>>
>> It would be extremely unfortunate if one of the very few decentralized
>> ways to
>> store value died simply because we couldn't find a way to pay to keep it
>> secure.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220619/58dc9f5b/attachment-0001.html>

2023-06-07 23:06:04

- reply

📅 Original date posted:2022-03-23
📝 Original message:Hey
On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is where, say, mainstream adoption has happened, some crisis of some magnitude happens that convinces a lot of people something needs to change now. Let's say it's another congestion period where fees spike for months. Getting into and out of lighting is hard and maybe even the security of lightning's security model is called into question because it would either take too long to get a transaction on chain or be too expensive. Panicy people might once again think something like "let's increase the block size to 1GB, then we'll never have this problem again". This could happen in a segwit-like soft fork.
Bitcoin has never been mainstream, and yet somehow you have known
where you needed to be, all the time. The same will apply then. This
is a non-issue.
>
> In a future where Bitcoin is the dominant world currency, it might not be unrealistic to imagine that an economic majority might not understand why such a thing would be so dangerous, or think the risk is low enough to be worth it. At that point, we in the economic minority would need a plan to hard fork away. One wouldn't necessarily need to sell all their majority fork Bitcoin, but they could.
Again, Bitcoin _is_ not an economic majority. Has never been. But
smart money always wins. This is a non-issue.
If one doesn't know where to be, there's the option to defer choices.
I was a big blocker myself, and yet I'm fairly OK even after being so
wrong. Even if forced to choose because of evil deadlines (which is
really unlikely), a divide strategy should be helpful enough to cut
losses in those cases.
>
> That minority fork would of course need some mining power. How much? I don't know, but we should think about how small of a minority chain we could imagine might be worth saving. Is 5% enough? 1%? How long would the chain stall if hash power dropped to 1%?
>
> TBH I give the world a ~50% chance that something like this happens in the next 100 years. Maybe Bitcoin will ossify and we'll lose all the people that had deep knowledge on these kinds of things because almost no one's actively working on it. Maybe the crisis will be too much for people to remain rational and think long term. Who knows? But I think that at some point it will become dangerous if there isn't a well discussed well vetted plan for what to do in such a scenario. Maybe we can think about that 10 years from now, but we probably shouldn't wait much longer than that. And maybe it's as simple as: tweak the difficulty recalculation and then just release a soft fork aware Bitcoin version that rejects the new rules or rejects a specific existing post-soft-fork block. Would it be that simple?
Maybe this is worth thinking about, but really, there'll always be
smart enough people around. However
dumb people sometimes are not as dangerous as we think, and
smart people sometimes are not as flawless as we desire to take for granted.
>
> On Sat, Mar 12, 2022, 07:35 Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> wrote:
>>>
>>>
>>>> A major contender to the Speedy Trial design at the time was to mandate eventual forced signalling, championed by luke-jr. It turns out that, at the time of that proposal, a large amount of hash power simply did not have the firmware required to support signalling. That activation proposal never got broad consensus, and rightly so, because in retrospect we see that the design might have risked knocking a significant fraction of mining power offline if it had been deployed. Imagine if the firmware couldn't be quickly updated or imagine if the problem had been hardware related.
>>>>>
>>>>>
>>>>> Yes, I like this solution too, with a little caveat: an easy mechanism for users to actively oppose a proposal.
>>>>> Luke alao talked about this.
>>>>> If users oppose, they should use activation as a trigger to fork out of the network by invalidating the block that produces activation.
>>>>> The bad scenario here is that miners want to deploy something but users don't want to.
>>>>> "But that may lead to a fork". Yeah, I know.
>>>>> I hope imagining a scenario in which developers propose something that most miners accept but some users reject is not taboo.
>>>>
>>>>
>>>> This topic is not taboo.
>>>>
>>>> There are a couple of ways of opting out of taproot. Firstly, users can just not use taproot. Secondly, users can choose to not enforce taproot either by running an older version of Bitcoin Core or otherwise forking the source code. Thirdly, if some users insist on a chain where taproot is "not activated", they can always softk-fork in their own rule that disallows the version bits that complete the Speedy Trial activation sequence, or alternatively soft-fork in a rule to make spending from (or to) taproot addresses illegal.
>>>
>>>
>>> Since it's about activation in general and not about taproot specifically, your third point is the one that applies.
>>> Users could have coordinated to have "activation x" never activated in their chains if they simply make a rule that activating a given proposal (with bip8) is forbidden in their chain.
>>> But coordination requires time.
>>
>>
>> A mechanism of soft-forking against activation exists. What more do you want? Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin? That simply isn't reasonable, but if you think it is, I invite you to create such a fork.
>>
>>>
>>> Please, try to imagine an example for an activation that you wouldn't like yourself. Imagine it gets proposed and you, as a user, want to resist it.
>>
>>
>> If I believe I'm in the economic majority then I'll just refuse to upgrade my node, which was option 2. I don't know why you dismissed it.
>>
>> Not much can prevent a miner cartel from enforcing rules that users don't want other than hard forking a replacement POW. There is no effective difference between some developers releasing a malicious soft-fork of Bitcoin and the miners releasing a malicious version themselves. And when the miner cartel forms, they aren't necessarily going to be polite enough to give a transparent signal of their new rules. However, without the economic majority enforcing their set of rules, the cartel continuously risks falling apart from the temptation of transaction fees of the censored transactions.
>>
>> On the other hand, If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin. Look, you cannot have the perfect system of money all by your lonesome self. Money doesn't have economic value if no one else wants to trade you for it. Just ask that poor user who YOLO'd his own taproot activation in advance all by themselves. I'm sure they think they've got just the perfect money system, with taproot early and everything. But now their node is stuck at block 692261 and hasn't made progress since. No doubt they are hunkered down for the long term, absolutely committed to their fork and just waiting for the rest of the world to come around to how much better their version of Bitcoin is than the rest of us.
>>
>> Even though you've dismissed it, one of the considerations of taproot was that it is opt-in for users to use the functionality. Future soft-forks ought to have the same considerations to the extent possible.
>> _______________________________________________
>> 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 23:00:16

- reply

📅 Original date posted:2021-10-20
📝 Original message:Hi Owen,
On Wed, Oct 20, 2021 at 9:25 PM Owen Gunden via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Oct 20, 2021 at 04:47:17PM +0200, Prayank wrote:
> > > It seems confusing to have two sites that seemingly both represent
> > > bitcoin core.
> >
> > There is only one website which represents Bitcoin Core full node
> > implementation. You can download Bitcoin Core from
> > https://bitcoincore.org
>
> I also notice that, as of 22.0, Wladimir is no longer signing the
> releases, and I have no trust in my gpg network of the people who seem
> to have replaced him.
>
He is taking the most sensible way forward, decreasing bus factor.
Read: https://laanwj.github.io/2021/01/21/decentralize.html
>
> Given the level of security at stake here, my eyebrows are raised at
> this combination of items changing (new website + new gpg signers at the
> same time).
>
Don't worry and build your own release;
but if you do, always verify the tree hash.
Trust signed annotated tags.
Cheers!
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211020/ab18e285/attachment.html>

2023-06-07 23:00:11

- reply

📅 Original date posted:2021-10-16
📝 Original message:Hi, BIP 42 is a code base consensus soft fork that at the time of
activation does not really manifest as a fork because nobody is running any
code not already applying it. Can a similar thing be done in 17 years? (I
haven't really made sense of this year 2038 problem, I don't know or
understand what is required if there's something to be done).
Cheers!
On Sat, Oct 16, 2021 at 11:00 PM David Bakin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> yes but ... just for the sake of argument ... if a change such as this
> wraparound interpretation is made anytime in the next 5 years it'll be over
> a *decade after that *before any wrapped-around timestamp is legitimately
> mined ... and by then nobody will be running incompatible (decade old) node
> software (especially since it would mean that a decade had gone by without
> a *single* consensus change ... seems very unlikely).
>
> On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the
>> appropriate time?
>>
>> The chain will halt for all old clients, because there is no 32-bit value
>> greater than 0xffffffff.
>>
>> > 1. Is not violated, since "not lower than" means "greater than or equal
>> to"
>>
>> No, because it has to be strictly "greater than" in the Bitcoin Core
>> source code, it is rejected when it is "lower or equal to", see:
>> https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094
>>
>> > 2. Is not violated, since it would be a past actual real time.
>>
>> If the current time is 0x0000000100000000, then the lowest 32 bits will
>> point to some time around 1970, so for old clients two rules are violated
>> at the same time.
>>
>> > 3. Is not violated since 0xFFFFFFFF < 0x100000000.
>>
>> This is hard to change, because 32-bit timestamps are included in block
>> headers, so using any wider data type here will make it
>> hardware-incompatible and will cause a hard-fork. That's why I think new
>> timestamps should be placed in the coinbase transaction. But that still
>> does not solve chain halting problem.
>>
>> To test chain halting, all that is needed is starting regtest and
>> producing one block with 0xffffffff timestamp, just after the Genesis
>> Block. Then, median time is equal to 0xffffffff and adding any new blocks
>> is no longer possible. The only soft-fork solution I can see require
>> overwriting that block.
>>
>> Example from https://bitcointalk.org/index.php?topic=5365359.0
>>
>> submitblock
>> 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
>> null
>> generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
>> CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp
>> is too early (code -1)
>>
>> I don't know any timestamp that can be used in any next block and
>> accepted by old nodes.
>>
>> On 2021-10-16 01:01:54 user ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>> > 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 +0000)
>>
>> What happens if a series of blocks has a timestamp of 0xFFFFFFFF 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 0xFFFFFFFF and 0xFFFFFFFF ==
>> 0xFFFFFFFF
>> 2. Is not violated, since it would be a past actual real time.
>> 3. Is not violated since 0xFFFFFFFF < 0x100000000.
>>
>> 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211016/25370194/attachment-0001.html>

2023-06-07 23:00:09

- reply

📅 Original date posted:2021-10-17
📝 Original message:Hi yanmaani
On Sun, Oct 17, 2021 at 5:28 PM yanmaani--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
>
"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).
>
> 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).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211017/a7bd292d/attachment.html>

2023-06-07 23:00:06

- reply

📅 Original date posted:2021-10-17
📝 Original message:There is a hard fork wishlist:
https://en.bitcoin.it/wiki/Hardfork_Wishlist
Note last update is somewhat old.
Cheers.
On Sat, Oct 16, 2021 at 12:49 AM James Lu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 at 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 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211017/db2469d9/attachment.html>