<unnamed>

Public Key

npub1kkr20dcfa7a27uqrlkryqwxangtngc9nmx9cdlpyp3yvq37s8wsqz7fx4e

Profile Code

nprofile1qqsttp48kuy7lw40wqplmpjq8rwe59e5vzeanzuxlsjqcjxqglgrhgqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds6yqph5

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:42:52 UTC

- reply

📅 Original date posted:2015-10-06
📝 Original message:>
>
> On Mon, Oct 5, 2015 at 11:20 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
> >> In this case, I don't even believe we have any regulator contributors
> >> that disagree.
> >
> > Since Gavin Andresen chose you to be one of 4 people who decides whose
> > contributions are accepted to the Core project, shouldn't you recuse
> > yourself from referencing "regular contributor" as some kind of bar to
> > an opinion being worthy?
> >
> > You don't want to be accused of squelching a person's opinions by
> > nacking or sitting on commits, then turning around and branding those
> > opinions as worthless because they are not from a "regular contributor."
> > Do you?
>
> Great point, Tom!
>
> In fact, you’ve just explained the dynamics that create “centralizing
> pressure” in regards to development: If the weight of a person’s opinion
> is proportional to how many commits that person has made, and if the
> probability of getting a commit pulled is proportional to the weight of
> that person’s opinion, well…I’m pretty sure this results in a differential
> equation that has a solution that results in ever-increasing centralized
> control of the code base.
>
Really great stuff, Mr. R! We can use differential equations to measure
centralization pressure (I'm pretty sure, good idea). If we want
decentralization (or even mere stability), we must impose a
counterbalancing rule such that each past commit makes one *less* likely to
get their next commit pulled. For example, a "one man one commit" policy.
>
> I believe we should work to deprecate the idea that Core is somehow the
> “core of Bitcoin," in favour of multiple competing implementations. XT and
> btcd are two working examples of this idea. Let’s make it easier for the
> community to determine the evolution of Bitcoin by making it easier for the
> community to express their vote based on the code we choose to run.
>
Yes, this is essential. Greg, stop making it so hard for me to determine
the evolution of Bitcoin by making it hard to express my vote based on the
code I choose to run. Blockstream is always doing that I am sick of it.
Mr. R really understands these concepts at a deep level and people need to
pay more attention to what he has to say. Nash equilibriums are very
important mathematical concept, for example:
https://www.reddit.com/r/Bitcoin/comments/3nhq5a/deprecating_bitcoin_core_visualizing_the/
>
> Best regards,
> Peter
> _______________________________________________
> 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/20151006/251be515/attachment-0001.html>

2023-06-07 17:42:46 UTC

- reply

📅 Original date posted:2015-10-06
📝 Original message:I think I can solve the debate and give everyone what they want.
Some people want BIP65, others do not.
We can roll out 65 in a clever way, such that Greg/PeterT can get it, but
Mike and Peter R don't need to have it (both versions can run alongside
each other). Even better, people can switch back and forth between versions
as much as they like.
How might this work? Well, paradoxically, we could do this by *imposing
additional constraints* on transaction validation, such that transactions
made a very specific certain way will always look valid to non-CLTVers, but
for CLTVers they will not be valid unless the CLTV rules are followed. The
obvious concern is that non-CLTV people might receive invalid payments.
However, their software is already set up to request payments in a non-CLTV
way, so, luckily, this is actually not a problem at all! SPV clients can
elect to only connect to nodes which are non-CLTV.
Problem solved!
I am happy to have solved this problem for you all, and ended this discord
harmoniously. If we all put our heads together, these words of founding
father Aretha Franklin will ring true: "there's nothing we can't overcome".
On Tue, Oct 6, 2015 at 3:29 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is childish and very disappointing to see.
>
> 2015-10-06 9:20 GMT+02:00 Eric Lombrozo via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> I prefer the term "clown".
>>
>> Can we please move on?
>>
>> ------ Original Message ------
>> From: "cipher anthem via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org>
>> To: milly at bitcoins.info
>> Cc: bitcoin-dev at lists.linuxfoundation.org
>> Sent: 10/6/2015 12:17:14 AM
>> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
>> technical debate
>>
>> Sent: Monday, October 05, 2015 at 8:21 PM
>>>> From: "Milly Bitcoin via bitcoin-dev" <
>>>> bitcoin-dev at lists.linuxfoundation.org>
>>>> To: bitcoin-dev at lists.linuxfoundation.org
>>>> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
>>>> technical debate
>>>> On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:
>>>>
>>>>> It's pretty clear Mike has turned into concern troll and bully.
>>>>>
>>>>
>>> "troll" and, even worse, "concern troll" are terms generally used by
>>>> teenagers on places like Reddit to complain about someone who doesn't
>>>> agree with them.
>>>>
>>>
>>> They should substitute troll for cultist so they appear more
>>> professional...
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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/20151006/7173bb2e/attachment.html>

2023-06-07 17:42:42 UTC

- reply

📅 Original date posted:2015-10-05
📝 Original message:For soft forks, consensus is required. In fact, we (today) have miners who
individually choose to mine blocks that are completely empty, with no known
input from (or communication with) the outside world. This is a consensus
process. Users can switch back and forth all they like, and this only
happens when there is unanimous miner-developer consensus. Most of the time
they don't even know, that they are under consensus.
It is only "controversial hard forks" which DON'T require wide agreement
and developer endorsements. Hear me out.
This is because, with zero dev-agreement, we have two benefits: first,
there are tremendous security issues which can be fixed by trying more than
one hard fork at once (these fixes can prevent loss of funds), and, second,
because each fork is equally Acked and Nacked (a Schrodinger's Ack, if you
will), they will have equal standing, and therefore users will be equally
indifferent to both forks and they will both live for a long time (and
users will be able to pick the fork that best fits them, empowering the
user).
People have overlooked how simple this issue is because of the political
climate. We need a climate change, pardon the pun.
On Mon, Oct 5, 2015 at 2:33 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote:
> > > Unsuccessfully.
> >
> > I think rather successfully.
>
> Arguing that BIP66 rollout was a full success is in the same park of
> "successful" ?
> Where for weeks people were told not to trust the longest chain until it
> was
> 30 blocks.
> Lets put that in perspective. The main functionality of Bitcoin
> Frankly, if that fiasco happened in a company, people would get fired for
> gross misconduct.
>
> Bottom line is that there is a horrible track record of doing soft forks in
> the past, there are some really good technical reasons why this should not
> happen again.
>
> And the defence against this argument is to do character assassination
> because
> you think he has ulterior motives? Like you say in this part;
>
> > That Mike himself continues to misexplain
> > things is not surprising since he has all but outright said that his
> > motivation here is to disrupt Bitcoin in order to try to force his
> > blocksize hardfork on people.
>
> "all but outright said" is still not said. Is still just a suspicion you
> have.
> And you are accusing a man of something he didn't do.
> That’s just not right.
>
> > > The point is that Bitcoin Core claims to have a consensus mechanism and
> > > sticks to "no change" on not reaching a consensus. And that rule is the
> > > reason why bigger blocks were blocked for years.
> >
> > You're repeating Mike's claims there-- not anyone elses. Take your
> > complaint up with him-- not the list.
>
> There is no complaint. Why do you think there is?
> Are you claiming that not reaching consensus is NOT the reason that bigger
> blocks are not in Bitcoin Core?
>
>
> Reaching consensus is an admirable goal. But its exactly that, a goal.
> And anyone that is a perfectionist will know that in the real world goals
> are
> often not reached. That doesn't make them less useful. That makes them
> goals.
> This specific goal is in conflict of building a good product and a well
> functioning community.
>
> A good product and a well functioning community needs rules and needs
> timely
> decisions and conflict resolution.
> It does not need muting of valuable voices, it does not need character
> assassinations and it really doesn't need egos.
>
> I suggest reading this book;
> http://www.artofcommunityonline.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/20151005/ff7bea8c/attachment-0001.html>

2023-06-07 17:41:57 UTC

- reply

📅 Original date posted:2015-10-01
📝 Original message:On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
> entirely avoidable.
>
> Make it a hard fork and my objection will be dropped.
>
> Until then, as there is no consensus, you need to do one of two things:
>
> 1) Drop the "everyone must agree to make changes" idea that people here
like
> to peddle, and do it loudly, so everyone in the community is correctly
> informed
>
> 2) Do nothing
>
>
I agree with Mike Hearn that there is no consensus on using a soft fork to
deploy this feature. Either everyone agrees that we should all agree on
consensus or else there is arbitrary disagreement. You cannot have it both
ways.
It is very important that we reach consensus on consensus or, if you will,
meta0consensus. I think we should Do nothing as that is clearly the choice
that we have taken re: blocksize. If we use one set of rules for that
decision we should use the same set of rules for all decisions and there is
no middle ground.
Thank you.
>
> _______________________________________________
> 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/20151001/4afdfa1b/attachment.html>