Samson Mow [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-02-09 to 2021-02-18
💬 Posted a total of 3 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-08-06 23:37:35

- reply

📅 Original date posted:2023-08-04
🗒️ Summary of this message: Wallet addresses generated from compromised or lost wallets can result in lost funds. Silent Payment addresses should have an expiration date, such as 180 years, to prevent this.
📝 Original message:
Why the 180 year limit? imho should plan for longer.
On Fri, Aug 4, 2023 at 10:41 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> tl;dr: Wallets don't last forever. They are often compromised or lost. When
> this happens, the addresses generated from those wallets become a form of
> toxic
> data: funds sent to those addresses can be easily lost forever.
>
> All Bitcoin addresses have this problem. But at least existing Bitcoin
> addresses aren't supposed to be reused. Silent Payments are: the whole
> point is
> to have a single address that you can safely pay to multiple times, without
> privacy concerns. Failing to make Silent Payment addresses eventually
> expire in
> a reasonable amount of time is thus a particularly harmful mistake.
>
> Fixing this is easy: add a 3 byte field to silent payments addresses,
> encoding
> the expiration date in terms of days after some epoch. 2^24 days is 45,000
> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days
> is 180
> years. We'll be lucky if Bitcoin still exists in 180 years.
>
> Wallets should pick a reasonable default, eg 1 year, for newly created
> addresses. Attempts to pay an expired address should just fail with a
> simple
> "address expired". Lightning invoices are a good example here: while
> invoices
> does not require expiration from a technical point of view, they do expire
> for
> similar UX reasons as applies to silent payments.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230804/fc013648/attachment-0001.html>

2023-08-06 23:37:35

- reply

2023-06-07 18:28:45

- reply

📅 Original date posted:2021-02-18
📝 Original message:"An activation mechanism is a consensus change like any other change, can
be contentious like any other change, and we must resolve it like any other
change. Otherwise we risk arriving at the darkest timeline."
Who's we here?
Release both and let the network decide.
On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for your response Ariel. It would be useful if you responded to
> specific points I have made in the mailing list post or at least quote
> these ephemeral "people" you speak of. I don't know if you're responding to
> conversation on the IRC channel or on social media etc.
>
> > The argument comes from a naive assumption that users MUST upgrade to
> the choice that is submitted into code. But in fact this isn't true and
> some voices in this discussion need to be more humble about what users must
> or must not run.
>
> I personally have never made this assumption. Of course users aren't
> forced to run any particular software version, quite the opposite. Defaults
> set in software versions matter though as many users won't change them.
>
> > Does no one realize that it is a very possible outcome that if LOT=true
> is released there may be only a handful of people that begin running it
> while everyone else delays their upgrade (with the very good reason of not
> getting involved in politics) and a year later those handful of people just
> become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?
>
> It is a possible outcome but the likely outcome is that miners activate
> Taproot before LOT is even relevant. I think it is prudent to prepare for
> the unlikely but possible outcome that miners fail to activate and hence
> have this discussion now rather than be unprepared for that eventuality. If
> LOT is set to false in a software release there is the possibility (T2 in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
> of individuals or a proportion of the community changing LOT to true. In
> that sense setting LOT=false in a software release appears to be no more
> safe than LOT=true.
>
> > The result: a wasted year of waiting and a minority of people who didn't
> want to be lenient with miners by default.
>
> There is the (unlikely but possible) possibility of a wasted year if LOT
> is set to false and miners fail to activate. I'm not convinced by this
> perception that LOT=true is antagonistic to miners. I actually think it
> offers them clarity on what will happen over a year time period and removes
> the need for coordinated or uncoordinated community UASF efforts on top of
> LOT=false.
>
> > An activation mechanism is a consensus change like any other change, can
> be contentious like any other change, and we must resolve it like any other
> change. Otherwise we risk arriving at the darkest timeline.
>
> I don't know what you are recommending here to avoid "this darkest
> timeline". Open discussions have occurred and are continuing and in my
> mailing list post that you responded to **I recommended we propose
> LOT=false be set in protocol implementations such as Bitcoin Core**. I do
> think this apocalyptic language isn't particularly helpful. In an open
> consensus system discussion is healthy, we should prepare for bad or worst
> case scenarios in advance and doing so is not antagonistic or destructive.
> Mining pools have pledged support for Taproot but we don't build secure
> systems based on pledges of support, we build them to minimize trust in any
> human actors. We can be grateful that people like Alejandro have worked
> hard on taprootactivation.com (and this effort has informed the
> discussion) without taking pledges of support as cast iron guarantees.
>
> TL;DR It sounds like you agree with my recommendation to set LOT=false in
> protocol implementations in my email :)
>
>
>
>
> On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
> arielluaces at gmail.com> wrote:
>
>> Something what strikes me about the conversation is the emotion
>> surrounding the letters UASF.
>>
>> It appears as if people discuss UASF as if it's a massive tidal wave of
>> support that is inevitable, like we saw during segwit activation. But the
>> actual definition is "any activation that is not a MASF".
>>
>> A UASF can consist of a single node, ten nodes, a thousand, half of all
>> nodes, all business' nodes, or even all the non mining nodes. On another
>> dimension it can have zero mining support, 51% support, 49% support, or any
>> support right up against a miner activation threshold.
>>
>> Hell a UASF doesn't even need code or even a single node running as long
>> as it exists as a possibility in people's minds.
>>
>> The only thing a UASF doesn't have is miner support above an agreed
>> activation threshold (some number above %51).
>>
>> I say this because it strikes me when people say that they are for
>> LOT=true with the logic that since a UASF is guaranteed to happen then it's
>> better to just make it default from the beginning. Words like coordination
>> and safety are sometimes sprinkled into the argument.
>>
>> The argument comes from a naive assumption that users MUST upgrade to the
>> choice that is submitted into code. But in fact this isn't true and some
>> voices in this discussion need to be more humble about what users must or
>> must not run.
>>
>> Does no one realize that it is a very possible outcome that if LOT=true
>> is released there may be only a handful of people that begin running it
>> while everyone else delays their upgrade (with the very good reason of not
>> getting involved in politics) and a year later those handful of people just
>> become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or
>> attracting a minority of miners, activating, and forking off into a
>> minority fork. Then a lot=false could be started that ends up activating
>> the feature now that the stubborn option has ran its course.
>> The result: a wasted year of waiting and a minority of people who didn't
>> want to be lenient with miners by default. The chains could be called
>> BitcoinLenient and BitcoinStubborn.
>> How is that strictly safer or more coordinated?
>>
>> I may be in the minority, or maybe a silent majority, or maybe a majority
>> that just hasn't considered this as a choice but honestly if there is
>> contention about whether we're going to be stubborn or lenient with miners
>> for Taproot and in the future then I prefer to just not activate anything
>> at all. I'm fine for calling bitcoin ossified, accepting that segwit is
>> Bitcoin's last network upgrade. Taproot is amazing but no new feature is
>> worth a network split down the middle.
>>
>> Maybe in 10 or 20 years, when other blockchains implement features like
>> Taproot and many more, we will become envious enough to put aside our
>> differences on how to behave towards miners and finally activate Taproot.
>>
>> An activation mechanism is a consensus change like any other change, can
>> be contentious like any other change, and we must resolve it like any other
>> change. Otherwise we risk arriving at the darkest timeline.
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>> On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Yesterday (February 16th) we held a second meeting on Taproot
>>> activation on IRC which again was open to all. Despite what appeared
>>> to be majority support for LOT=false over LOT=true in the first
>>> meeting I (and others) thought the arguments had not been explored in
>>> depth and that we should have a follow up meeting almost entirely
>>> focused on whether LOT (lockinontimeout) should be set to true or
>>> false.
>>>
>>> The meeting was announced here:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
>>>
>>> In that mailing list post I outlined the arguments for LOT=true (T1 to
>>> T6) and arguments for LOT=false (F1 to F6) in their strongest form I
>>> could. David Harding responded with an additional argument for
>>> LOT=false (F7) here:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
>>>
>>> These meetings are very challenging given they are open to all, you
>>> don’t know who will attend and you don’t know most people’s views in
>>> advance. I tried to give time for both the LOT=true arguments and the
>>> LOT=false arguments to be discussed as I knew there was support for
>>> both. We only tried evaluating which had more support and which had
>>> more strong opposition towards the end of the meeting.
>>>
>>> The conversation log is here:
>>> http://gnusha.org/taproot-activation/2021-02-16.log
>>>
>>> (If you are so inclined you can watch a video of the meeting here.
>>> Thanks to the YouTube account “Bitcoin” for setting up the livestream:
>>> https://www.youtube.com/watch?v=vpl5q1ovMLM)
>>>
>>> A summary of the meeting was provided by Luke Dashjr on Mastodon here:
>>> https://bitcoinhackers.org/@lukedashjr/105742918779234566
>>>
>>> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
>>> did manage to come to consensus on everything but LockinOnTimeout.
>>>
>>> Activation height range: 693504-745920
>>>
>>> MASF threshold: 1815/2016 blocks (90%)
>>>
>>> Keep in mind only ~100 people showed for the meetings, hardly
>>> representative of the entire community.
>>>
>>> So, these details remain JUST a proposal for now.
>>>
>>> It seems inevitable that there won't be consensus on LOT.
>>>
>>> Everyone will have to choose for himself. :/
>>>
>>> Personally I agree with most of this. I agree that there wasn’t
>>> overwhelming consensus for either LOT=true or LOT=false. However, from
>>> my perspective there was clearly more strong opposition (what would
>>> usually be deemed a NACK in Bitcoin Core review terminology) from
>>> Bitcoin Core contributors, Lightning developers and other community
>>> members against LOT=true than there was for LOT=false. Andrew Chow
>>> tried to summarize views from the meeting in this analysis:
>>> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
>>>
>>> I am also aware of other current and previous Bitcoin Core
>>> contributors and Lightning developers who didn’t attend the meeting in
>>> person who are opposed to LOT=true. I don’t want to put them in the
>>> spotlight for no reason but if you go through the conversation logs of
>>> not only the meeting but the weeks of discussion prior to this meeting
>>> you will see their views evaluated on the ##taproot-activation
>>> channel. In addition, on taprootactivation.com some mining pools
>>> expressed a preference for lot=false though I don’t know how strong
>>> that preference was.
>>>
>>> I am only one voice but it is my current assessment that if we are to
>>> attempt to finalize Taproot activation parameters and propose them to
>>> the community at this time our only option is to propose LOT=false.
>>> Any further delay appears to me counterproductive in our collective
>>> aim to get the Taproot soft fork activated as early as possible.
>>>
>>> Obviously others are free to disagree with that assessment and
>>> continue discussions but personally I will be attempting to avoid
>>> those discussions unless prominent new information comes to light or
>>> various specific individuals change their minds.
>>>
>>> Next week we are planning a code review of the Bitcoin Core PR #19573
>>> which was initially delayed because of this LOT discussion. As I’ve
>>> said previously that will be loosely following the format of the
>>> Bitcoin Core PR review club and will be lower level and more
>>> technical. That is planned for Tuesday February 23rd at 19:00 UTC on
>>> the IRC channel ##taproot-activation.
>>>
>>> Thanks to the meeting participants (and those who joined the
>>> discussion on the channel prior and post the meeting) for engaging
>>> productively and in good faith.
>>>
>>>
>
> --
> Michael Folkson
> Email: michaelfolkson at gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> 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/20210218/ff91bcfb/attachment-0001.html>

2023-06-07 18:28:45

- reply

2023-06-07 17:58:45

- reply

📅 Original date posted:2017-04-01
📝 Original message:A compromise for the sake of compromise doesn't merit technical
discussions. There are no benefits to be gained from a 2MB hard-fork at
this time and it would impose an unnecessary cost to the ecosystem for
testing and implementation.
On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> Hey Sergio,
>>
>> You appear to have ignored the last two years of Bitcoin hardfork
>> research and understanding, recycling instead BIP 102 from 2015. There
>> are many proposals which have pushed the state of hard fork research
>> much further since then, and you may wish to read some of the posts on
>> this mailing list listed at https://bitcoinhardforkresearch.github.io/
>> and make further edits based on what you learn.
>
>
> I've read every proposal that was published in the last two years and the
> choice for NOT implementing any of the super cool research you cite is
> intentional.
>
> We're in a deadlock and it seems we can't go forward adding more
> functionality to segwit without the community approval (which include
> miners). This is obvious to me.Then we have to go back.
>
> If this last resort solution is merged, we could go back to discuss
> improvements with the
>
> Your goal of "avoid
>> technical changes" appears to not have any basis outside of perceived
>> compromise for compromise sake, only making such a hardfork riskier
>> instead.
>>
>> You're are totally correct. It's a compromise for the compromise sake. I
> couldn't have expressed it more clearly. However the only "riskier" element
> is the hard forking date. We can move the date forward.
>
>
>> At a minimum, in terms of pure technical changes, you should probably
>> consider (probably among others):
>>
> a) Utilizing the "hard fork signaling bit" in the nVersion of the block.
>>
>
> This I could consider, as it requires probably a single line of code.
> Which BIP specifies this?
>
>
>> b) Either limiting non-SegWit transactions in some way to fix the n**2
>> sighash and FindAndDelete runtime and memory usage issues or fix them by
>> utilizing the new sighash type which many wallets and projects have
>> already implemented for SegWit in the spending of non-SegWit outputs.
>>
>
> The Seghash problem has already been addressed by limiting the maximum
> size of a transaction to 1 Mb.
> The FindAndDelete problem has already been solved by the Core Developers,
> so we don't have to worry about it anymore.
>
>
>> c) Your really should have replay protection in any HF.
>
>
> We could add a simple protection, although if we reach community consensus
> and 95% of hashing power, does we really need to? Can the old chain still
> be alive?
> If more people ask for replay protection, I will merge Spoonet scheme or
> develop the minimum possible replay protection (a simple signaling bit in
> transaction version)
>
>
>> d) You may wish to consider the possibility of tweaking the witness
>> discount and possibly discounting other parts of the input - SegWit went
>> a long ways towards making removal of elements from the UTXO set cheaper
>> than adding them, but didn't quite get there, you should probably finish
>> that job. This also provides additional tuneable parameters to allow you
>> to increase the block size while not having a blowup in the worst-case
>> block size.
>>
>
> That is an interesting economic change and would be out of the scope of
> segwit2mb.
>
>
>> e) Additional commitments at the top of the merkle root - both for
>> SegWit transactions and as additional space for merged mining and other
>> commitments which we may wish to add in the future, this should likely
>> be implemented an "additional header" ala Johnson Lau's Spoonnet proposal.
>>
>> That is an interesting technical improvement that is out of the scope of
> segwit2mb.
> We can keep discussing spoonet while we merge segwit2mb, as spoonnet
> includes most of technical innovations.
>
>
>> Additionally, I think your parameters here pose very significant risk to
>> the Bitcoin ecosystem broadly.
>>
>> a) Activating a hard fork with less than 18/24 months (and even then...)
>> from a fully-audited and supported release of full node software to
>> activation date poses significant risks to many large software projects
>> and users. I've repeatedly received feedback from various folks that a
>> year or more is likely required in any hard fork to limit this risk, and
>> limited pushback on that given the large increase which SegWit provides
>> itself buying a ton of time.
>>
>> The feedback I received is slightly different from your feedback. Many
> company CTOs have expressed that one year for a Bitcoin hard-fork was
> period they could schedule a secure upgrade.
>
>
>
>> b) Having a significant discontinuity in block size increase only serves
>> to confuse and mislead users and businesses, forcing them to rapidly
>> adapt to a Bitcoin which changed overnight both by hardforking, and by
>> fees changing suddenly. Instead, having the hard fork activate technical
>> changes, and then slowly increasing the block size over the following
>> several years keeps things nice and continuous and also keeps us from
>> having to revisit ye old blocksize debate again six months after
>> activation.
>>
>> This is something worth considering. There is the old Pieter BIP103
> proposal has good parameters (17.7% per year).
>
> c) You should likely consider the effect of the many technological
>> innovations coming down the pipe in the coming months. Technologies like
>> Lightning, TumbleBit, and even your own RootStock could significantly
>> reduce fee pressure as transactions move to much faster and more
>> featureful systems.
>>
>> RSK sidechain team would have to take very tough decisions if Bitcoin
> splits, as RSK platform cannot be pegged to two different cryptocurrencies.
> We could launch two platforms, but RSK value proposition is "supporting the
> advance of Bitcoin, the cryptocurrecy with highest network effect". You
> understand that if Bitcoin splits Bitcoin BTC/BTU separately may cease to
> be the cryptocurrencies with higher volume/market cap/network effect.
>
> Therefore all RSK people that I talked too would prefer to avoid a split
> at all cost, reather that to be the winners of the scaling war.
>
>
>
>> On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >Hi everyone,
>> >
>> >Segwit2Mb is the project to merge into Bitcoin a minimal patch that
>> >aims to
>> >untangle the current conflict between different political positions
>> >regarding segwit activation vs. an increase of the on-chain blockchain
>> >space through a standard block size increase. It is not a new solution,
>> >but
>> >it should be seen more as a least common denominator.
>> >
>> >Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
>> >block
>> >size hard-fork activated ONLY if segwit activates (95% of miners
>> >signaling), but at a fixed future date.
>> >
>> >The sole objective of this proposal is to re-unite the Bitcoin
>> >community
>> >and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
>> >possible technical solution to solve Bitcoin technical limitations.
>> >However, this proposal does not imply a compromise to the future
>> >scalability or decentralization of Bitcoin, as a small increase in
>> >block
>> >size has been proven by several core and non-core developers not to
>> >affect
>> >Bitcoin value propositions.
>> >
>> >In the worst case, a 2X block size increase has much lower economic
>> >impact
>> >than the last bitcoin halving (<10%), which succeeded without problem.
>> >
>> >On the other side, Segwit2Mb primary goal is to be minimalistic: in
>> >this
>> >patch some choices have been made to reduce the number of lines
>> >modified in
>> >the current Bitcoin Core state (master branch), instead of implementing
>> >the
>> >most elegant solution. This is because I want to reduce the time it
>> >takes
>> >for core programmers and reviewers to check the correctness of the
>> >code,
>> >and to report and correct bugs.
>> >
>> >The patch was built by forking the master branch of Bitcoin Core,
>> >mixing a
>> >few lines of code from Jeff Garzik's BIP102, and defining a second
>> >versionbits activation bit (bit 2) for the combined activation.
>> >
>> >The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
>> >(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
>> >
>> >This means that segwit can still be activated without the 2MB hard-fork
>> >by
>> >signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
>> >
>> >The tentative lock-in and hard-fork dates are the following:
>> >
>> >Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
>> >
>> >Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
>> >
>> >HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
>> >
>> >
>> >The hard-fork is conditional to 95% of the hashing power has approved
>> >the
>> >segwit2mb soft-fork and the segwit soft-fork has been activated (which
>> >should occur 2016 blocks after its lock-in time)
>> >
>> >For more information on how soft-forks are signaled and activated, see
>> >https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
>> >
>> >This means that segwit would be activated before 2Mb: this is
>> >inevitable,
>> >as versionbits have been designed to have fixed activation periods and
>> >thresholds for all bits. Making segwit and 2Mb fork activate together
>> >at a
>> >delayed date would have required a major re-write of this code, which
>> >would
>> >contradict the premise of creating a minimalistic patch. However, once
>> >segwit is activated, the hard-fork is unavoidable.
>> >
>> >Although I have coded a first version of the segwit2mb patch (which
>> >modifies 120 lines of code, and adds 220 lines of testing code), I
>> >would
>> >prefer to wait to publish the source code until more comments have been
>> >received from the community.
>> >
>> >To prevent worsening block verification time because of the O(N^2)
>> >hashing
>> >problem, the simple restriction that transactions cannot be larger than
>> >1Mb
>> >has been kept. Therefore the worse-case of block verification time has
>> >only
>> >doubled.
>> >
>> >Regarding the hard-fork activation date, I want to give enough time to
>> >all
>> >active economic nodes to upgrade. As of Fri Mar 31 2017,
>> >https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
>> >have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can
>> >be
>> >used to identify economic active nodes, because in the 0.12 release
>> >dynamic
>> >fees were introduced, and currently no Bitcoin automatic payment system
>> >can
>> >operate without automatic discovery of the current fee rate. A pre-0.12
>> >would require constant manual intervention.
>> >Therefore I conclude that no more than 91% of the network nodes
>> >reported by
>> >bitnodes are active economic nodes.
>> >
>> >As Bitcoin Core 0.12 was released on February 2016, the time for this
>> >91%
>> >to upgrade has been around one year (under a moderate pressure of
>> >operational problems with unconfirmed transactions).
>> >Therefore we can expect a similar or lower time to upgrade for a
>> >hard-fork,
>> >after developers have discussed and approved the patch, and it has been
>> >reviewed and merged and 95% of the hashing power has signaled for it
>> >(the
>> >pressure not to upgrade being a complete halt of the operations).
>> >However I
>> >suggest that we discuss the hard-fork date and delay it if there is a
>> >real
>> >need to.
>> >
>> >Currently time works against the Bitcoin community, and so is delaying
>> >a
>> >compromise solution. Most of the community agree that halting the
>> >innovation for several years is a very bad option.
>> >
>> >After the comments collected by the community, a BIP will be written
>> >describing the resulting proposal details.
>> >
>> >If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should
>> >be
>> >updated to a Segwit2Mb enabled node to prevent them to be forked-away
>> >in a
>> >chain with almost no hashing-power.
>> >
>> >The proof of concept patch was made for Bitcoin Core but should be
>> >easily
>> >ported to other Bitcoin protocol implementations that already support
>> >versionbits. Lightweight (SPV) wallets should not be affected as they
>> >generally do not check the block size.
>> >
>> >I personally want to see the Lightning Network in action this year, use
>> >the
>> >non-malleability features in segwit, see the community discussing other
>> >exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains
>> >and
>> >MAST.
>> >
>> >I want to see miners, developers and industry side-by-side pushing
>> >Bitcoin
>> >forward, to increase the value of Bitcoin and prevent high transaction
>> >fees
>> >to put out of business use-cases that could have high positive social
>> >impact.
>> >
>> >I believe in the strength of a unified Bitcoin community. If you're a
>> >developer, please give your opinion, suggest changes, audit it, and
>> >take a
>> >stand with me to unlock the current Bitcoin deadlock.
>> >
>> >Contributions to the segwit2mb project are welcomed and awaited. The
>> >only
>> >limitation is to stick to the principle that the patch should be as
>> >simple
>> >to audit as possible. As an example, I wouldn't feel confident if the
>> >patch
>> >modified more than ~150 lines of code.
>> >
>> >Improvements unrelated to a 2 Mb increase or segwit, as beneficial as
>> >it
>> >may be to Bitcoin, should not be part of segwit2Mb.
>> >
>> >This proposal should not prevent other consensus proposals to be
>> >simultaneously merged: segwit2mb is a last resort solution in case we
>> >can
>> >not reach consensus on anything better.
>> >
>> >Again, the proposal is only a starting point: community feedback is
>> >expected and welcomed.
>> >
>> >Regards,
>> >Sergio Demian Lerner
>>
>
>
> _______________________________________________
> 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/20170331/b05637e8/attachment-0001.html>

2023-06-07 17:58:45

- reply

2023-06-07 17:48:40

- reply

📅 Original date posted:2016-02-09
📝 Original message:Gavin, please don't quote that list on the Classic website. It's horribly
inaccurate and misleading to the general public.
> That testing is happening by the exchange, library, wallet, etc providers
> themselves. There is a list on the Classic home page:
>
> https://bitcoinclassic.com/
I know for a fact that most companies you list there have no intention to
run Classic, much less test it. You should not mix support for 2MB with
support for Classic, or if people say they welcome a fork, to mean they
support Classic.
On Sun, Feb 7, 2016 at 5:11 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev
> wrote:
> > On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam at cypherspace.org> wrote:
> >
> > >
> > > It would probably be a good idea to have a security considerations
> > > section
> >
> >
> > Containing what? I'm not aware of any security considerations that are
> any
> > different from any other consensus rules change.
>
> I covered the security considerations unique to hard-forks on my blog:
>
> https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
>
> > > , also, is there a list of which exchange, library, wallet,
> > > pool, stats server, hardware etc you have tested this change against?
> > >
> >
> > That testing is happening by the exchange, library, wallet, etc providers
> > themselves. There is a list on the Classic home page:
> >
> > https://bitcoinclassic.com/
>
> How do we know any of this testing is actually being performed? I don't
> currently know of any concrete testing actually done.
>
> > > Do you have a rollback plan in the event the hard-fork triggers via
> > > false voting as seemed to be prevalent during XT? (Or rollback just
> > > as contingency if something unforseen goes wrong).
> > >
> >
> > The only voting in this BIP is done by the miners, and that cannot be
> faked.
>
> Are you unaware of Not Bitcoin XT?
>
> https://bitcointalk.org/index.php?topic=1154520.0
>
> > I can't imagine any even-remotely-likely sequence of events that would
> > require a rollback, can you be more specific about what you are
> imagining?
> > Miners suddenly getting cold feet?
>
> See above.
>
> Also, as the two coins are separate currencies and can easily trade
> against each other in a 75%/25% split, it would be easy for the price to
> diverge and hashing power to move.
>
> In fact, I've been asked multiple times now by exchanges and other
> players in this ecosystem for technical advice on how to split coins
> across the chains effectively (easily done with nLockTime). Notably, the
> exchanges who have asked me this - who hold customer funds on their
> behalf - have informed me that their legal advice was that the
> post-hard-fork coins are legally speaking separate currencies, and
> customers must be given the opportunity to transact in them separately
> if they choose too. Obviously, with a 75%/25% split, while block times
> on the other chain will be slower, the chain is still quite useful and
> nearly as secure as the main chain against 51% attack; why I personally
> have suggested a 99% threshold:
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.html
>
> (remember that the threshold can always be soft-forked down)
>
> It's also notable that millions of dollars of Bitcoin are voting agsast
> the fork on the proof-of-stake voting site Bitcoinocracy.com While
> obviously not comprehensive, the fact that a relatively obscure site
> like it can achieve participation like that, even without an easy to use
> user friendly interface.
>
> > > How do you plan to monitor and manage security through the hard-fork?
> > >
> >
> > I don't plan to monitor or manage anything; the Bitcoin network is
> > self-monitoring and self-managing. Services like statoshi.info will do
> the
> > monitoring, and miners and people and businesses will manage the network,
> > as they do every day.
>
> Please provide details on exactly how that's going to happen.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
>
> _______________________________________________
> 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/20160209/021a7b73/attachment.html>

2023-06-07 17:48:40

- reply