Steven Pine [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-05-08 to 2017-05-23
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:00:39

- reply

📅 Original date posted:2017-05-23
📝 Original message:I'm glad some discussion has been moved back here.
Correct me if I am wrong, but currently core developers are arguing over
whether or not to allow an optional configuration switch which defaults off
but signals and enforces BIP148 when used. Who are we protecting users
from, themselves? Are you protecting core? from what? I am somewhat
genuinely befuddled by those who can't even allow a user config switch to
be set.
I guess I find it all incredibly silly, but perhaps I suffer from some
basic confusion.
On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I also do not support the BIP 148 UASF, and I'd like to add to the points
> that Greg has already raised in this thread.
>
> BIP 148 would introduce a new consensus rule that softforks out non-segwit
> signalling blocks in some time period. I reject this consensus rule as
> both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to
> reach consensus on the state of a shared ledger, and even though I think
> the Bitcoin network ought to adopt segwit, I don't think that concern
> trumps the goal of not splitting the network.
>
> Many BIP 148 advocates seem to start with the assumption that segwit
> already has a lot of support, and suggest that BIP 148 does as well.
> However I don't think it's fair or correct to separate the activation
> proposal for segwit from the rest of the segwit proposal. The deployment
> parameters for segwit are consensus-critical; assuming that some other
> deployment has consensus because it would result in the rest of the segwit
> proposal activating is an unjustified leap.
>
> Even if there were no feasible alternate segwit deployment method
> available to us, I would hesitate to recommend that the network adopt a
> potentially consensus-splitting approach, even though I firmly believe that
> the ideas behind segwit are fundamentally good ones. But fortunately that
> is not the situation we are in; we have substantially less disruptive
> methods available to us to activate it, even if the current BIP 9
> deployment were to fail -- such as another BIP 9 deployment in the future,
> or perhaps a BIP 149 deployment.
>
> If we do pursue a "user-activated" deployment of segwit, I'd recommend
> that we do so in a more careful way than BIP 148 or 149 currently suggest,
> which as I understand would otherwise make very few changes to the current
> implementation. However, due to the BIP 9 activation assumption, the
> Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
> the idea that miners would both enforce the rules and mine segwit blocks.
> However, we can separate these concerns, as we started to do in the Bitcoin
> Core 0.14.1 release, where mining segwit blocks is not required in order to
> generally mine or signal for segwit in the software. And we can go further
> still: without too much work, we could make further improvements to
> accommodate miners who, for whatever reason, don't want to upgrade their
> systems, such as by improving block relay from pre-segwit peers [1], or
> optimizing transaction selection for miners who are willing to enforce the
> segwit rules but haven't upgraded their systems to mine segwit blocks [2].
>
> If we would seek to activate a soft-fork with less clear miner signaling
> (such as BIP 149), then I think such improvements are warranted to minimize
> network disruption. In general, we should not seek to censor hashpower on
> the network unless we have a very important reason for doing so. While the
> issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
> proposal on the spectrum of "censorship attack on Bitcoin" to "benign
> protocol upgrade", BIP 148 strikes me as closer to the former than the
> latter. There is simply no need here to orphan these non-signalling blocks
> that could otherwise be used to secure the network.
>
> To go further: I think BIP 148 is ill-conceived even for achieving its own
> presumed goals -- the motivation for adding a consensus rule that applies
> to the version bits on blocks is surely for the effect such bits have on
> older software, such as Bitcoin Core releases 0.13.1 and later. Yet in
> trying to bring those implementations along as segwit-enforcing software,
> BIP 148 would risk forking from such clients in the short term! If one
> really cared about maintaining consensus with older, segwit-enabled
> software, it would make far more sense to seek segwit activation in a way
> that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
> after this one times out). And if one doesn't care about such consensus,
> then it'd be far simpler to just set (e.g.) August 1 as the flag day
> activation of segwit, and not play these contortionist games with block
> version bits, which carry no useful or intrinsic meaning. Either of these
> two approaches should have the advantage of reduced fork risk, compared
> with BIP 148.
>
> Of course, everyone is free to run the software of their choosing. I
> write this to both generally convey my opposition to a careless proposal,
> which I believe represents a way of thinking that is detrimental to
> Bitcoin's long run success, and specifically explain why I oppose inclusion
> of this proposal in the Bitcoin Core implementation [3]. The Bitcoin Core
> project hasn't been, and shouldn't be, careless in deploying consensus
> changes. Instead, I think the Bitcoin Core project ought to stand up for
> the best practices that our community has learned about how to deploy such
> changes (specifically for minimizing chain-split risk when deploying a soft
> fork!), and I think we should all avoid adoption or encouragement of
> practices that would depart from the high standards we are capable of
> achieving.
>
>
> [1] https://lists.linuxfoundation.org/pipermail/
> bitcoin-dev/2017-March/013811.html
> [2] https://github.com/bitcoin/bitcoin/pull/9955
> [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
>
>
> --Suhas Daftuar
>
>
> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I do not support the BIP148 UASF for some of the same reasons that I
>> do support segwit: Bitcoin is valuable in part because it has high
>> security and stability, segwit was carefully designed to support and
>> amplify that engineering integrity that people can count on now and
>> into the future.
>>
>> I do not feel the the approach proposed in BIP148 really measures up
>> to the standard set by segwit itself, or the existing best practices
>> in protocol development in this community.
>>
>> The primary flaw in BIP148 is that by forcing the activation of the
>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
>> of disruption.
>>
>> Segwit was carefully engineered so that older unmodified miners could
>> continue operating _completely_ without interruption after segwit
>> activates.
>>
>> Older nodes will not include segwit spends, and so their blocks will
>> not be invalid even if they do not have segwit support. They can
>> upgrade to it on their own schedule. The only risk non-participating
>> miners take after segwit activation is that if someone else mines an
>> invalid block they would extend it, a risk many miners already
>> frequently take with spy-mining.
>>
>> I do not think it is a horrible proposal: it is better engineered than
>> many things that many altcoins do, but just not up to our normal
>> standards. I respect the motivations of the authors of BIP 148. If
>> your goal is the fastest possible segwit activation then it is very
>> useful to exploit the >80% of existing nodes that already support the
>> original version of segwit.
>>
>> But the fastest support should not be our goal, as a community-- there
>> is always some reckless altcoin or centralized system that can support
>> something faster than we can-- trying to match that would only erode
>> our distinguishing value in being well engineered and stable.
>>
>> "First do no harm." We should use the least disruptive mechanisms
>> available, and the BIP148 proposal does not meet that test. To hear
>> some people-- non-developers on reddit and such-- a few even see the
>> forced orphaning of 148 as a virtue, that it's punitive for
>> misbehaving miners. I could not not disagree with that perspective any
>> more strongly.
>>
>> Of course, I do not oppose the general concept of a UASF but
>> _generally_ a soft-fork (of any kind) does not need to risk disruption
>> of mining, just as segwit's activation does not. UASF are the
>> original kind of soft-fork and were the only kind of fork practiced by
>> Satoshi. P2SH was activated based on a date, and all prior ones were
>> based on times or heights. We introduced miner based activation as
>> part of a process of making Bitcoin more stable in the common case
>> where the ecosystem is all in harmony. It's kind of weird to see UASF
>> portrayed as something new.
>>
>> It's important the users not be at the mercy of any one part of the
>> ecosystem to the extent that we can avoid it-- be it developers,
>> exchanges, chat forums, or mining hardware makers. Ultimately the
>> rules of Bitcoin work because they're enforced by the users
>> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
>> something people can count on: the rules aren't easy to just change.
>>
>> There have been some other UASF proposals that avoid the forced
>> disruption-- by just defining a new witness bit and allowing
>> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
>> think they are vastly superior. They would be slower to deploy, but I
>> do not think that is a flaw.
>>
>> We should have patience. Bitcoin is a system that should last for all
>> ages and power mankind for a long time-- ten years from now a couple
>> years of dispute will seem like nothing. But the reputation we earn
>> for stability and integrity, for being a system of money people can
>> count on will mean everything.
>>
>> If these discussions come up, they'll come up in the form of reminding
>> people that Bitcoin isn't easily changed at a whim, even when the
>> whims are obviously good, and how that protects it from being managed
>> like all the competing systems of money that the world used to use
>> were managed. :)
>>
>> So have patience, don't take short cuts. Segwit is a good improvement
>> and we should respect it by knowing that it's good enough to wait for,
>> and for however its activated to be done the best way we know how.
>> _______________________________________________
>> 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
>
>
--
Steven Pine
(510) 517-7075
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170523/6d4ec9c9/attachment.html>

2023-06-07 18:00:07

- reply

📅 Original date posted:2017-04-15
📝 Original message:I don't want to be rude and I will refer to your expertise, but segwit does
have a 'time out' as defined in BIP 9 with the date of November 15th? Does
core plan on just releasing another BIP with a new timeout hoping it will
eventually get 95% census?
As for the other point, we can play semantics but that's boring, I guess my
meaning was every census change has gone through a core defined process
(not counting the changes that occurred before there were BIPs and such),
isn't that the case? If the currently discussed UASF goes through it would
seem like the first time census occurred outside core's mailing list of
pull requests, acks, and merge to master, I only note it as a thing of
interest.
To be clear, the fast and reckless part for you is the mechanism by which
segwit could possibly be made active? Do you envision a means of segwit
being made consensus that does not have 95% mining support?
I appreciate your time and expertise, and to not take up anymore, back to
lurking i go.
On Fri, Apr 14, 2017 at 11:29 PM, Gregory Maxwell <greg at xiph.org> wrote:
> On Sat, Apr 15, 2017 at 2:01 AM, Steven Pine via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Regarding this last point I was under the impression that if Segwit did
> not
> > activate by November then core was going to move on, is that no longer
> the
>
> Wow. Where did you get that idea? That is _absurd_ and untrue, and I
> struggle a bit to even comprehend how someone could believe it. It
> would continue until something clearly better came along or people
> lost interest in it, why would it be anything else?
>
> > census change that was not rolled out and done by the core team? I only
> > mention this because BIP148, if it goes ahead (and is successful), would
> be
> > the first time a consensus change occurs outside of the core developers
> --
> > but again I am not an expert on the history of changes and could be
> wrong, I
>
> There is a definitional issue there. There isn't much of "the core
> team" there is a lot of amorphous public collaboration; everything
> ends up being retroactively defined as the core team. With open
> participation and hundreds of contributors and software running
> everywhere in the network, its unlikely that someone would advance to
> the point of being able to make a credible proposal without at some
> point making some improvement to the project or without the help of
> someone who has.
>
> In some sense you are coming very close to asking for a list of people
> who have contributed to Bitcoin without contributing to Bitcoin.
>
> CLTV was a proposal by Peter Todd whom has done a number of other
> things in core but AFAIR had no involvement in any prior soft-fork
> (though perhaps I'm forgetting one?), though he subsequently
> contributed to BIP66 (which activated before CLTV), and he contributed
> mostly after-the fact review of segwit. CSV was mostly the work of
> Mark Friedenbach whom I believe was not involved in any prior or
> subsequent soft-fork (and whos total contributions to Bitcoin core
> weigh in at 14 commits over 5 years).
>
> > My impression is that the community is ready for this and wants it, and
> if
> > that impression is correct it will go ahead. No one knows the future, and
> > simply assuming it's better to be slow and methodical isn't especially
>
> I am not suggesting slow. I am suggesting that we not be outright
> reckless. Some people are expecting changes which are effectively
> orders of magnitude faster than changes in centralized systems
> elsewhere which are far easier and safer to take quickly.
>
> (Some more comparatives here:
> https://www.reddit.com/r/Bitcoin/comments/65bch8/gregory_maxwell_i_do_not_
> support_the_bip_148_uasf/dg9xfam/
> )
>
> > Technology is in someways the history of failure,
>
> By all means, take risks-- but you don't get to choose to make other
> peoples things fail; you certainly don't get to demand their support,
> though you could try to earn it if you care, by figuring out how to
> meet their concerns.
>
--
Steven Pine
(510) 517-7075
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170415/e046d7dd/attachment.html>

2023-06-07 18:00:06

- reply

📅 Original date posted:2017-04-14
📝 Original message:> Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.
Regarding this last point I was under the impression that if Segwit did not
activate by November then core was going to move on, is that no longer the
case, does the core team plan on trying to activate Segwit in some other
way?
I am also curious, but has there been a softfork, hardfork, or other major
census change that was not rolled out and done by the core team? I only
mention this because BIP148, if it goes ahead (and is successful), would be
the first time a consensus change occurs outside of the core developers --
but again I am not an expert on the history of changes and could be wrong,
I only bring this up because core developers have in the past stressed they
are a part of the bitcoin ecosystem and not the drivers of it (at least
that is the ideal it seems).
My impression is that the community is ready for this and wants it, and if
that impression is correct it will go ahead. No one knows the future, and
simply assuming it's better to be slow and methodical isn't especially
convincing. Technology is in someways the history of failure, we like to
celebrate the seemingly sudden breakthroughs and successes but it's rare
that the original innovator retains a monopoly on their invention, more
often it becomes quickly refined and iterated upon as market forces take
hold to bring costs down and other external political issues
take precedence, all this is say that in ten years everyone could be
chuckling over the 3 year bitcoin scaling debate, or they could be using
litecoin, or ethereum or some other crypto coin, or something entirely
different, no one knows.
On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I do not support the BIP148 UASF for some of the same reasons that I
> do support segwit: Bitcoin is valuable in part because it has high
> security and stability, segwit was carefully designed to support and
> amplify that engineering integrity that people can count on now and
> into the future.
>
> I do not feel the the approach proposed in BIP148 really measures up
> to the standard set by segwit itself, or the existing best practices
> in protocol development in this community.
>
> The primary flaw in BIP148 is that by forcing the activation of the
> existing (non-UASF segwit) nodes it almost guarantees at a minor level
> of disruption.
>
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
>
> Older nodes will not include segwit spends, and so their blocks will
> not be invalid even if they do not have segwit support. They can
> upgrade to it on their own schedule. The only risk non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it, a risk many miners already
> frequently take with spy-mining.
>
> I do not think it is a horrible proposal: it is better engineered than
> many things that many altcoins do, but just not up to our normal
> standards. I respect the motivations of the authors of BIP 148. If
> your goal is the fastest possible segwit activation then it is very
> useful to exploit the >80% of existing nodes that already support the
> original version of segwit.
>
> But the fastest support should not be our goal, as a community-- there
> is always some reckless altcoin or centralized system that can support
> something faster than we can-- trying to match that would only erode
> our distinguishing value in being well engineered and stable.
>
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test. To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
>
> Of course, I do not oppose the general concept of a UASF but
> _generally_ a soft-fork (of any kind) does not need to risk disruption
> of mining, just as segwit's activation does not. UASF are the
> original kind of soft-fork and were the only kind of fork practiced by
> Satoshi. P2SH was activated based on a date, and all prior ones were
> based on times or heights. We introduced miner based activation as
> part of a process of making Bitcoin more stable in the common case
> where the ecosystem is all in harmony. It's kind of weird to see UASF
> portrayed as something new.
>
> It's important the users not be at the mercy of any one part of the
> ecosystem to the extent that we can avoid it-- be it developers,
> exchanges, chat forums, or mining hardware makers. Ultimately the
> rules of Bitcoin work because they're enforced by the users
> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
> something people can count on: the rules aren't easy to just change.
>
> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.
>
> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.
>
> If these discussions come up, they'll come up in the form of reminding
> people that Bitcoin isn't easily changed at a whim, even when the
> whims are obviously good, and how that protects it from being managed
> like all the competing systems of money that the world used to use
> were managed. :)
>
> So have patience, don't take short cuts. Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Steven Pine
(510) 517-7075
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/1bf09a08/attachment.html>

2023-06-07 17:48:49

- reply

📅 Original date posted:2016-02-07
📝 Original message:I agree that it seems like a safe assumption that adoption would be faster,
whether it is "very safe" and "significantly faster", whether it will be 6
times faster, all of those assumptions seems significantly less safe and
robust to me.
The nature of the bitcoin protocol, that it is a decentralized census based
protocol involving currency, suggests to me that roll out schedules ought
to be conservative with a minimum of assumptions. In light of the most
recent protocol upgrade, 6 months for this hard fork seems to me to be the
most conservative time frame with the fewest assumptions.
As for why it needs to be so fast, ie what are the dangers of it being as
slow as 6 months?
Gavin writes:
"I strongly disagree with the statement that there is no cost to a longer
grace period. There is broad agreement that a capacity increase is needed
NOW."
~~
"Broad agreement", that really seems to be another assumption, the fact
that the debate has been as long and acrimonious as it has been suggests
that there isn't broad agreement. Also, resorting to "SHOUTING" doesn't win
any favors when it comes to engaging in reasonable discussion om the
technical merits of a proposal.
On Sun, Feb 7, 2016 at 5:04 PM, Corey Haddad <corey3 at gmail.com> wrote:
> We don't have any evidence of how fast nodes will upgrade when faced with
> an impending hard fork, but it seems like a very safe assumption that the
> upgrade pace will be significantly faster. The hard fork case it is:
> "upgrade or be kicked off the network". In the previous cases it has been,
> "here's the latest and greatest, give it a go!". Also, there will be
> alerts sent out warning people of the situation, prompting them to take
> action.
>
> It is unclear if this will translate into more or less than 6x the
> adoption speed of previous instances, but the idea that it would be faster
> is solid. 28 days is aggressive, but again, it is only 28 days from when
> the fork triggers. Compatible software is already available for anyone who
> wants to prepare.
>
> It is also of significance that this proposed fork, and this debate, has
> been going on for many, many months. If someone proposed a forking concept
> today, wrote the BIP tomorrow, deployed it next week, miners adopted it
> instantly, and 28 days later it was the flag day, those 28 days would be in
> a different context. There is no surprise here.
>
> On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
>> it Gavin --
>>
>> ~
>> "We can look at the adoption of the last major Bitcoin core release to
>> guess how long it might take people to upgrade. 0.11.0 was released on 12
>> July, 2015. Twenty eight days later, about 38% of full nodes were
>> running that release. Three months later, about 50% of the network was
>> running that release, and six months later about 66% of the network was
>> running some flavor of 0.11."
>>
>> On what grounds do you think it is reasonable to assume that this update
>> will roll out 6x faster than previous data suggested, as oppose to your own
>> observation of 66% adoption in 6 month. or do you believe 38% node
>> upgrade-coverage (in 28 days ) on the network for a hard fork is good
>> enough?
>>
>> There are no harm in choosing a longer grace period but picking one short
>> as 28 days you risk on alienating the nodes who do not upgrade with the
>> aggressive upgrade timeline you proposed.
>> ~~
>>
>> When Gavin writes "Responding to "28 days is not long enough" :
>>
>> I keep seeing this claim made with no evidence to back it up. As I said,
>> I surveyed several of the biggest infrastructure providers and the btcd
>> lead developer and they all agree "28 days is plenty of time."
>>
>> For individuals... why would it take somebody longer than 28 days to
>> either download and restart their bitcoind, or to patch and then re-run
>> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
>> 2000000)?"
>>
>> ~~
>>
>> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
>> propositional a priori logic, but empirical evidence that. As for why
>> people take longer, who knows, we simply know from passed experience that
>> it in fact does take longer.
>>
>> It's extremely frustrating to read Gavin's comments, it's hard to believe
>> he is engaging in earnest discussion.
>>
>> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>>> wrote:
>>> > > > If you have a node that is "old" your node will stop getting new
>>> > > > blocks. The node will essentially just say "x-hours behind" with
>>> "x"
>>> > > > getting larger every hour. Funds don't get confirmed. etc.
>>> > >
>>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe
>>> more
>>> > > blocks confirming a large 10000 BTC payment. If you're just a normal
>>> end
>>> > > user (or perhaps an automated system), you'll figure that payment is
>>> good
>>> > > and irreversibly hand over the title to the house.
>>> >
>>> > There will be approximately zero percentage of hash power left on the
>>> > weaker branch of the fork, based on past soft-fork adoption by miners
>>> (they
>>> > upgrade VERY quickly from 75% to over 95%).
>>>
>>> I'm assuming there are literally ZERO miners left on the weaker branch.
>>> The attacker in this scenario simply rents hashing for a few days in
>>> advance
>>> to build his fake chain, then broadcasts the blocks to the unsuspecting
>>> merchant at ~10 block intervals so it looks like everything is working
>>> normal
>>> again. There are lots of mining rental services out there, and miners
>>> quite
>>> often do not care to avoid selling hashrate to the highest bidder
>>> regardless
>>> of what they're mining. 10 blocks worth costs a little more than 250 BTC
>>> -
>>> soon, that will be 125 BTC.
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> --
>> Steven Pine
>> (510) 517-7075
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--
Steven Pine
(510) 517-7075
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/4f03a475/attachment-0001.html>

2023-06-07 17:48:45

- reply

📅 Original date posted:2016-02-07
📝 Original message:Is it me or did Gavin ignore Yifu's direct questions? In case you missed it
Gavin --
~
"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."
On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage (in 28 days ) on the network for a hard fork is good
enough?
There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
~~
When Gavin writes "Responding to "28 days is not long enough" :
I keep seeing this claim made with no evidence to back it up. As I said, I
surveyed several of the biggest infrastructure providers and the btcd lead
developer and they all agree "28 days is plenty of time."
For individuals... why would it take somebody longer than 28 days to either
download and restart their bitcoind, or to patch and then re-run (the patch
can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?"
~~
Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
propositional a priori logic, but empirical evidence that. As for why
people take longer, who knows, we simply know from passed experience that
it in fact does take longer.
It's extremely frustrating to read Gavin's comments, it's hard to believe
he is engaging in earnest discussion.
On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
> wrote:
> > > > If you have a node that is "old" your node will stop getting new
> > > > blocks. The node will essentially just say "x-hours behind" with "x"
> > > > getting larger every hour. Funds don't get confirmed. etc.
> > >
> > > Until someone decides to attack you. Then you'll get 6, 10, maybe more
> > > blocks confirming a large 10000 BTC payment. If you're just a normal
> end
> > > user (or perhaps an automated system), you'll figure that payment is
> good
> > > and irreversibly hand over the title to the house.
> >
> > There will be approximately zero percentage of hash power left on the
> > weaker branch of the fork, based on past soft-fork adoption by miners
> (they
> > upgrade VERY quickly from 75% to over 95%).
>
> I'm assuming there are literally ZERO miners left on the weaker branch.
> The attacker in this scenario simply rents hashing for a few days in
> advance
> to build his fake chain, then broadcasts the blocks to the unsuspecting
> merchant at ~10 block intervals so it looks like everything is working
> normal
> again. There are lots of mining rental services out there, and miners quite
> often do not care to avoid selling hashrate to the highest bidder
> regardless
> of what they're mining. 10 blocks worth costs a little more than 250 BTC -
> soon, that will be 125 BTC.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Steven Pine
(510) 517-7075
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/3d005df7/attachment.html>

2023-06-07 17:42:44

- reply

📅 Original date posted:2015-10-05
📝 Original message:It's pretty clear Mike has turned into concern troll and bully. He insults
people, mischaracterizes others, quibbles over words and definitions and
has stated numerous times in other forums he has no interest in building
consensus changes he doesn't agree with himself.
He's lost his integrity and trust and why the core developers waste their
time with his antics is beyond me, let Mike fork Bitcoin, develop XT, and
ignore his input on core unless some XT feature is deemed good enough to
incorporate, that is how a thousand other open source projects deal with
trolls like Mike.
On Oct 5, 2015 3:41 PM, "Gregory Maxwell via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > It is an eloquent change, but not really the topic we were discussing.
> It also
> > makes you attack Mike (calling him out as having a strawman) without
> basis.
> > For the second time in this thread.
> > I would suggest arguing on the topic, not on the man.
>
> Such a shame you appear to reserve that wisdom for those you disagree
> with, biting your tongue when others emit all forms of ad hominem--
> such as suggesting we've spent less volunteer time on Bitcoin and thus
> our opinion has less merit (or that we haven't written certian kinds
> of software (even when, ironically, we have!), and thus our opinion
> doesn't have merit, and so on). I think everyone would benefit from
> it, especially as that kind of correction is best received from
> someone who agrees with you.
>
> In this case, I think, however your correction is also misplaced at
> least on this message; though I would otherwise welcome it. I'm not
> complaining about the man; but pointing out the behavior of stating an
> opinion no one as held as theirs and attacking it is not a productive
> way to hold a discussion. It's an argument or a behavior, not a
> person, and beyond calling it bad I attempted to explaining (perhaps
> poorly) why its bad.
>
> What Sergio is saying is not the same; Mike argued some established
> criteria existed where it didn't-- and I was pointing that out; and
> talking about how the situation here is not very similar to the one
> that Mike was trying to draw a parallel to. I enumerated a number of
> specific reasons why this is the case. If the differences between
> Sergio's comments and mine are still unclear after this clarification,
> I'd be glad to talk it through with you off-list-- in spite of your
> (welcome) compliments, communication is just fundamentally difficult,
> and no amount eloquence changes that. If there is continued
> misunderstanding, I do not doubt its my fault; but it's probably not a
> good use of hundreds/thousands of people's time for you to help me
> interactively improve my explanation on list. :)
> _______________________________________________
> 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/20151005/bcabeadc/attachment.html>

2023-06-07 17:40:38

- reply

📅 Original date posted:2015-09-20
📝 Original message:That's a simple fallacy, historically governments even hegemons, fail, in
fact it would be odd to assert that a government will not fail, therefore
ascribing godlike and limitless powers to a government is again the view of
either a shill or someone untutored in history.
On Sun, Sep 20, 2015 at 5:10 PM, NxtChg <nxtchg at hush.com> wrote:
>
> >Anyone who doesn't consider governments the proper threat model is either
> a shill or an idiot.
>
> You meant to say "threat". This is what threat model is:
> https://en.wikipedia.org/wiki/Threat_model
>
> Nobody here discounts governments as a threat.
>
> As to the "proper threat model", you can't construct one since your
> attacker is essentially unbounded.
>
> For example, any large government could easily obtain 51% of hash power
> and then only accept transactions from "certified services".
>
>
--
Steven Pine
(510) 517-7075
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150920/23655cdc/attachment-0001.html>

2023-06-07 17:40:34

- reply

📅 Original date posted:2015-09-20
📝 Original message:It's amazing how foolish some people are to continue trusting governments
especially in light of recent history: a seemingly endless, Orwellian 'war
on terror', multiple regional conflicts often justified by fake evidence,
wholesale disregard of law and basic human covenants such as do not
torture, ubiquitous and secret global surveillance.
Anyone who doesn't consider governments the proper threat model is either a
shill or an idiot.
On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Until this is settled, Bitcoin has no clear direction and developers
>> cannot make effective decisions:
>>
>
> How exactly do things set "settled" in this environment?
>
> People looking at Bitcoin think a small group of developers and miners
> "control" these decisions. Not sure if "control" is the right word but
> that is the perception.
>
> Russ
>
>
> _______________________________________________
> 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/20150920/47ac3c80/attachment.html>

2023-06-07 15:34:12

- reply

📅 Original date posted:2015-05-28
📝 Original message:I would support a dynamic block size increase as outlined. I have a few
questions though.
Is scaling by average block size the best and easiest method, why not scale
by transactions confirmed instead? Anyone can write and relay a
transaction, and those are what we want to scale for, why not measure it
directly?
I would prefer changes every 2016 blocks, it is a well known change and a
reasonable time period for planning on changes. Two weeks is plenty fast,
especially at a 50% rate increase, in a few months the block size could be
dramatically larger.
Daily change to size seems confusing especially considering that max block
size will be dipping up and down. Also if something breaks trying to fix it
in a day seems problematic. The hard fork database size difference error
comes to mind. Finally daily 50% increases could quickly crowd out smaller
nodes if changes happen too quickly to adapt for.
> Date: Thu, 28 May 2015 11:53:41 -0400
> From: Gavin Andresen <gavinandresen at gmail.com>
> Subject:
> To: Matt Whitlock <bip at mattwhitlock.name>
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Message-ID:
> <
CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
>
> > Between all the flames on this list, several ideas were raised that did
> > not get much attention. I hereby resubmit these ideas for consideration
and
> > discussion.
> >
> > - Perhaps the hard block size limit should be a function of the actual
> > block sizes over some trailing sampling period. For example, take the
> > median block size among the most recent 2016 blocks and multiply it by
1.5.
> > This allows Bitcoin to scale up gradually and organically, rather than
> > having human beings guessing at what is an appropriate limit.
> >
>
> A lot of people like this idea, or something like it. It is nice and
> simple, which is really important for consensus-critical code.
>
> With this rule in place, I believe there would be more "fee pressure"
> (miners would be creating smaller blocks) today. I created a couple of
> histograms of block sizes to infer what policy miners are ACTUALLY
> following today with respect to block size:
>
> Last 1,000 blocks:
> http://bitcoincore.org/~gavin/sizes_last1000.html
>
> Notice a big spike at 750K -- the default size for Bitcoin Core.
> This graph might be misleading, because transaction volume or fees might
> not be high enough over the last few days to fill blocks to whatever limit
> miners are willing to mine.
>
> So I graphed a time when (according to statoshi.info) there WERE a lot of
> transactions waiting to be confirmed:
> http://bitcoincore.org/~gavin/sizes_357511.html
>
> That might also be misleading, because it is possible there were a lot of
> transactions waiting to be confirmed because miners who choose to create
> small blocks got lucky and found more blocks than normal. In fact, it
> looks like that is what happened: more smaller-than-normal blocks were
> found, and the memory pool backed up.
>
> So: what if we had a dynamic maximum size limit based on recent history?
>
> The average block size is about 400K, so a 1.5x rule would make the max
> block size 600K; miners would definitely be squeezing out transactions /
> putting pressure to increase transaction fees. Even a 2x rule (implying
> 800K max blocks) would, today, be squeezing out transactions / putting
> pressure to increase fees.
>
> Using a median size instead of an average means the size can increase or
> decrease more quickly. For example, imagine the rule is "median of last
> 2016 blocks" and 49% of miners are producing 0-size blocks and 51% are
> producing max-size blocks. The median is max-size, so the 51% have total
> control over making blocks bigger. Swap the roles, and the median is
> min-size.
>
> Because of that, I think using an average is better-- it means the max
size
> will change (up or down) more slowly.
>
> I also think 2016 blocks is too long, because transaction volumes change
> quicker than that. An average over 144 blocks (last 24 hours) would be
> better able to handle increased transaction volume around major holidays,
> and would also be able to react more quickly if an economically irrational
> attacker attempted to flood the network with fee-paying transactions.
>
> So my straw-man proposal would be: max size 2x average size over last 144
> blocks, calculated at every block.
>
> There are a couple of other changes I'd pair with that consensus change:
>
> + Make the default mining policy for Bitcoin Core neutral-- have its
target
> block size be the average size, so miners that don't care will "go along
> with the people who do care."
>
> + Use something like Greg's formula for size instead of bytes-on-the-wire,
> to discourage bloating the UTXO set.
>
>
> ---------
>
> When I've proposed (privately, to the other core committers) some dynamic
> algorithm the objection has been "but that gives miners complete control
> over the max block size."
>
> I think that worry is unjustified right now-- certainly, until we have
> size-independent new block propagation there is an incentive for miners to
> keep their blocks small, and we see miners creating small blocks even when
> there are fee-paying transactions waiting to be confirmed.
>
> I don't even think it will be a problem if/when we do have
size-independent
> new block propagation, because I think the combination of the random
timing
> of block-finding plus a dynamic limit as described above will create a
> healthy system.
>
> If I'm wrong, then it seems to me the miners will have a very strong
> incentive to, collectively, impose whatever rules are necessary (maybe a
> soft-fork to put a hard cap on block size) to make the system healthy
again.
>
>
> --
> --
> Gavin Andresen
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
------------------------------------------------------------------------------
>
>
> ------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> End of Bitcoin-development Digest, Vol 48, Issue 122
> ****************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/9bc538ee/attachment.html>

2023-06-07 15:34:12

- reply

📅 Original date posted:2015-05-28
📝 Original message:My understanding, which is very likely wrong in one way or another, is
transaction size and block size are two slightly different things but
perhaps it's so negligible that block size is a fine stand-in for total
transaction throughput.
Potentially Doubling the block size everyday is frankly imprudent. The
logarithmic increases in difficulty, which were often closer to 10% or 20%
every 2016 blocks was and is plenty fast, potentially changing blocksize by
twice daily is the mentality I would expect from a startup with the move
fast break things motto.
Infrastructure takes time, not everyone wants to run a node on a virtual
amazon instance, provisioning additional hard drive and bandwidth can't
happen overnight and trying to plan when block size from one week to the
next is a total mystery would be extremely difficult.
Anyone who has spent time examining the mining difficulty increases and
trajectory knows future planning is very very hard, allowing block size to
double daily would make it impossible.
Perhaps a middle way would be 300% increase every 2016 blocks, that will
scale to 20mbs within a month or two
The problem is logarithmic increases seem slow until they seem fast. If the
network begins to grow and block size hits 20, then the next day 40, 80...
Small nodes could get swamped within a week or less.
As for your point about Christmas, Bitcoin is a global network, Christmas,
while widely celebrated, isn't the only holiday, and planning around
American buying habits seems short sighted and no different from developers
trying to choose what the right fee pressure is.
On May 28, 2015 1:22 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
> On Thu, May 28, 2015 at 12:30 PM, Steven Pine <steven.pine at gmail.com>
wrote:
>>
>> I would support a dynamic block size increase as outlined. I have a few
questions though.
>>
>> Is scaling by average block size the best and easiest method, why not
scale by transactions confirmed instead? Anyone can write and relay a
transaction, and those are what we want to scale for, why not measure it
directly?
>
>
> What do you mean? Transactions aren't confirmed until they're in a
block...
>
>>
>> I would prefer changes every 2016 blocks, it is a well known change and
a reasonable time period for planning on changes. Two weeks is plenty fast,
especially at a 50% rate increase, in a few months the block size could be
dramatically larger.
>
>
> What type of planning do you imagine is necessary?
>
> And have you looked at transaction volumes for credit-card payment
networks around Christmas?
>
>>
>> Daily change to size seems confusing especially considering that max
block size will be dipping up and down. Also if something breaks trying to
fix it in a day seems problematic. The hard fork database size difference
error comes to mind. Finally daily 50% increases could quickly crowd out
smaller nodes if changes happen too quickly to adapt for.
>
> The bottleneck is transaction volume; blocks won't get bigger unless
there are fee-paying transactions around to pay them. What scenario are you
imagining where transaction volume increases by 50% a day for a sustained
period of time?
>
> --
> --
> Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/6daaf026/attachment.html>

2023-06-07 15:34:12

- reply

📅 Original date posted:2015-05-08
📝 Original message:Block size scaling should be as transparent and simple as possible, like
pegging it to total transactions per difficulty change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/4c72c004/attachment.html>