Nostr notes by

📅 Original date posted:2015-10-01 📝 Original message:Or, ...

2023-06-07T17:41:57Z

In reply to nevent1q…7hdc
_________________________

📅 Original date posted:2015-10-01
📝 Original message:Or, you know, enter some discussions on what exactly are the issues that SPV
clients face during soft forks and see if anything can be done (on all
sides) to mitigate the risks.

Crazy stuff, I know Š ;-)

From: NotMike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Reply-To: NotMike Hearn <not.mike.hearn at gmail.com>
Date: Friday, 2 October 2015 9:57 am
To: <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

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
>

_______________________________________________ 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/20151002/f95134ba/attachment-0001.html>;

📅 Original date posted:2015-08-17 📝 Original message:Adam, ...

2023-06-07T17:36:08Z

In reply to nevent1q…hsdg
_________________________

📅 Original date posted:2015-08-17
📝 Original message:Adam,

While greatly appreciating your prior efforts in crypto-ccy R&D and
current efforts for Blockstream, its not a plus for your reputation to be
using emotive terms like ³attack², ³fork war" and throwing so much FUD
into the developer email channel directly after Eric¹s email.

We would appreciate seeing your well-argued thoughts, not FUD and flaming.
There are multitudes of trolls in all forums already.

On 17/8/15 10:36 pm, "Adam Back via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org> wrote:

>Thank you Eric for saying what needs to be said.
>
>Starting a fork war is just not constructive and there are multiple
>proposals being evaluated here.
>
>I think that one thing that is not being so much focussed on is
>Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
>Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
>SPV nodes that did not opt-in. It exposes those SPV nodes to loss in
>the likely event that Bitcoin-XT results in a network-split.
>
>The recent proposal here to run noXT (patch to falsely claim to mine
>on XT while actually rejecting it's blocks) could add enough
>uncertainty about the activation that Bitcoin-XT would probably have
>to be aborted.
>
>Adam
>
>On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>> NxtChg,
>>
>> In the entire history of Bitcoin we¹ve never attempted anything even
>>closely resembling a hard fork like what¹s being proposed here.
>>
>> Many of us have wanted to push our own hard-forking changes to the
>>protocolŠand have been frustrated because of the inability to do so.
>>
>> This inability is not due to any malice on anyone¹s partŠit is a
>>feature of Satoshi¹s protocol. For better or worse, it is *very hard* to
>>change the rulesŠand this is exactly what imbues Bitcoin with one of its
>>most powerful attributes: very well-defined settlement guarantees that
>>cannot be suddenly altered nor reversed by anyone.
>>
>> We¹ve managed to have a few soft forks in the pastŠand for the most
>>part these changes have been pretty uncontroversialŠor at least, they
>>have not had nearly the level of political divisiveness that this block
>>size issue is having. And even then, we¹ve encountered a number of
>>problems with these deployments that have at times required goodwill
>>cooperation between developers and mining pool operators to fix.
>>
>> Again, we have NEVER attempted anything even remotely like what¹s being
>>proposed - we¹ve never done any sort of hard fork before like this. If
>>even fairly uncontroversial soft forks have caused problems, can you
>>imagine the kinds of potential problems that a hard fork over some
>>highly polarizing issue might raise? Do you really think people are
>>going to want to cooperate?!?
>>
>> I can understand that some people would like bigger blocks. Other
>>people might want feature X, others feature YŠand we can argue the
>>merits of this or that to deathŠbut the fact remains that we have NEVER
>>attempted any hard forking changeŠnot even with a simple, totally
>>uncontroversial no-brainer improvement that would not risk any sort of
>>ill-will that could hamper remedies were it not to go as smoothly as we
>>like. *THIS* is the fundamental problem - the whole bigger block thing
>>is a minor issue by comparisonŠit could be any controversial change,
>>really.
>>
>> Would you want to send your test pilots on their first flightŠthe first
>>time an aircraft is ever flownŠdirectly into combat without having
>>tested the plane? This is what attempting a hard fork mechanism that¹s
>>NEVER been done before in such a politically divisive environment
>>basically amounts toŠbut it¹s even worse. We¹re basically risking the
>>entire air force (not just one plane) over an argument regarding how
>>many seats a plane should have that we¹ve never flown before.
>>
>> We¹re talking billlions of dollars¹ worth of other people¹s money that
>>is on the line here. Don¹t we owe it to them to at least test out the
>>system on a far less controversial, far less divisive change first to
>>make sure we can even deploy it without things breaking? I don¹t even
>>care about the merits regarding bigger blocks vs. smaller blocks at this
>>point, to be quite honest - that¹s such a petty thing compared to what
>>I¹m talking about here. If we attempt a novel hard-forking mechanism
>>that¹s NEVER been attempted before (and which as many have pointed out
>>is potentially fraught with serious problems) on such a politically
>>divisive, polarizing issue, the result is each side will refuse to
>>cooperate with the other out of spiteŠand can easily lead to a war,
>>tanking the value of everyone¹s assets on both chains. All so we can
>>process 8 times the number of transactions we currently do? Even if it
>>were 100 times, we wouldn¹t even come close to touching big payment
>>processors like Visa. It¹s hard to imagine a protocol improvement that¹s
>>worth the risk.
>>
>> I urge you to at least try to see the bigger picture hereŠand to
>>understand that nobody is trying to stop anyone from doing anything out
>>of some desire for maintaining control - NONE of us are able to deploy
>>hard forks right now without facing these problems. And different people
>>obviously have different priorities and preferences as to which of these
>>changes would be best to do first. This whole XT thing is essentially
>>giving *one* proposal special treatment above those that others have
>>proposed. Many of us have only held back from doing this out of our
>>belief that goodwill amongst network participants is more important than
>>trying to push some pet feature some of us want.
>>
>> Please stop this negativity - we ALL want the best for Bitcoin and are
>>doing our best, given what we understand and know, to do what¹s right.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-08-19 📝 Original message:Can ...

2023-06-07T17:35:54Z

In reply to nevent1q…kc4h
_________________________

📅 Original date posted:2015-08-19
📝 Original message:Can this anecdote and similar be removed from the mailing list.

Possibly one of the reddits is a better place for this kind of thing.

On 20/8/15 7:56 am, "Jorge Timón via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org> wrote:

>By the way, now that I remember why I subscribed to the libbitcoin
>list I want to share it with you.
>I met Amir Taaki in person in a spanish hackmeeting and had the chance
>to talk a lot with him, very interesting person whose input in this
>blocksize matter I would greatly appreciate. He explained some of his
>concerns with Bitcoin Core (Bitcoin-qt at the time) and he
>specifically named 2 persons: Mike Hearn and Gavin Andresen. If I
>remember correctly, Hearn had recently proposed a blacklisting scheme
>for Bitcoin.
>
>I remember I said something along the lines:
>"Mike Hearn has certainly proposed some nasty things but I don't think
>other devs will ever accept that kind of changes in Bitcoin-qt.
>Regarding Gavin, I believe he is someone that can be trusted even if
>he visited the CIA. If anything, I think he is overly conservative
>about some changes, but that's very understandable given how fragile
>Bitcoin is (specially at this early stage)".
>
>Looking back, I now realize that his concerns were not exaggerated at
>all and I was clearly wrong thinking Gavin was overly conservative.
>He was also worried about the payment protocol and we agreed to
>disagree there (maybe I should read all the payment protocol stuff
>more deeply).
>
>I don't want this to be taken as an argument of authority "Mike and
>Gavin cannot be trusted because Amir didn't trust them", just as a
>curious anecdote.
>Amir, I wouldn't like to put words in your mouth: that's why I cc'ed
>you so you can correct me in case my memory is failing.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-08-17 📝 Original message:Adam, ...

2023-06-07T15:47:46Z

In reply to nevent1q…9whl
_________________________

📅 Original date posted:2015-08-17
📝 Original message:Adam,

While greatly appreciating your prior efforts in crypto-ccy R&D and
current efforts for Blockstream, its not a plus for your reputation to be
using emotive terms like ³attack², ³fork war" and throwing so much FUD
into the developer email channel directly after Eric¹s email.

We would appreciate seeing your well-argued thoughts, not FUD and flaming.
There are multitudes of trolls in all forums already.

On 17/8/15 10:36 pm, "Adam Back via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org> wrote:

>Thank you Eric for saying what needs to be said.
>
>Starting a fork war is just not constructive and there are multiple
>proposals being evaluated here.
>
>I think that one thing that is not being so much focussed on is
>Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
>Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
>SPV nodes that did not opt-in. It exposes those SPV nodes to loss in
>the likely event that Bitcoin-XT results in a network-split.
>
>The recent proposal here to run noXT (patch to falsely claim to mine
>on XT while actually rejecting it's blocks) could add enough
>uncertainty about the activation that Bitcoin-XT would probably have
>to be aborted.
>
>Adam
>
>On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>> NxtChg,
>>
>> In the entire history of Bitcoin we¹ve never attempted anything even
>>closely resembling a hard fork like what¹s being proposed here.
>>
>> Many of us have wanted to push our own hard-forking changes to the
>>protocolŠand have been frustrated because of the inability to do so.
>>
>> This inability is not due to any malice on anyone¹s partŠit is a
>>feature of Satoshi¹s protocol. For better or worse, it is *very hard* to
>>change the rulesŠand this is exactly what imbues Bitcoin with one of its
>>most powerful attributes: very well-defined settlement guarantees that
>>cannot be suddenly altered nor reversed by anyone.
>>
>> We¹ve managed to have a few soft forks in the pastŠand for the most
>>part these changes have been pretty uncontroversialŠor at least, they
>>have not had nearly the level of political divisiveness that this block
>>size issue is having. And even then, we¹ve encountered a number of
>>problems with these deployments that have at times required goodwill
>>cooperation between developers and mining pool operators to fix.
>>
>> Again, we have NEVER attempted anything even remotely like what¹s being
>>proposed - we¹ve never done any sort of hard fork before like this. If
>>even fairly uncontroversial soft forks have caused problems, can you
>>imagine the kinds of potential problems that a hard fork over some
>>highly polarizing issue might raise? Do you really think people are
>>going to want to cooperate?!?
>>
>> I can understand that some people would like bigger blocks. Other
>>people might want feature X, others feature YŠand we can argue the
>>merits of this or that to deathŠbut the fact remains that we have NEVER
>>attempted any hard forking changeŠnot even with a simple, totally
>>uncontroversial no-brainer improvement that would not risk any sort of
>>ill-will that could hamper remedies were it not to go as smoothly as we
>>like. *THIS* is the fundamental problem - the whole bigger block thing
>>is a minor issue by comparisonŠit could be any controversial change,
>>really.
>>
>> Would you want to send your test pilots on their first flightŠthe first
>>time an aircraft is ever flownŠdirectly into combat without having
>>tested the plane? This is what attempting a hard fork mechanism that¹s
>>NEVER been done before in such a politically divisive environment
>>basically amounts toŠbut it¹s even worse. We¹re basically risking the
>>entire air force (not just one plane) over an argument regarding how
>>many seats a plane should have that we¹ve never flown before.
>>
>> We¹re talking billlions of dollars¹ worth of other people¹s money that
>>is on the line here. Don¹t we owe it to them to at least test out the
>>system on a far less controversial, far less divisive change first to
>>make sure we can even deploy it without things breaking? I don¹t even
>>care about the merits regarding bigger blocks vs. smaller blocks at this
>>point, to be quite honest - that¹s such a petty thing compared to what
>>I¹m talking about here. If we attempt a novel hard-forking mechanism
>>that¹s NEVER been attempted before (and which as many have pointed out
>>is potentially fraught with serious problems) on such a politically
>>divisive, polarizing issue, the result is each side will refuse to
>>cooperate with the other out of spiteŠand can easily lead to a war,
>>tanking the value of everyone¹s assets on both chains. All so we can
>>process 8 times the number of transactions we currently do? Even if it
>>were 100 times, we wouldn¹t even come close to touching big payment
>>processors like Visa. It¹s hard to imagine a protocol improvement that¹s
>>worth the risk.
>>
>> I urge you to at least try to see the bigger picture hereŠand to
>>understand that nobody is trying to stop anyone from doing anything out
>>of some desire for maintaining control - NONE of us are able to deploy
>>hard forks right now without facing these problems. And different people
>>obviously have different priorities and preferences as to which of these
>>changes would be best to do first. This whole XT thing is essentially
>>giving *one* proposal special treatment above those that others have
>>proposed. Many of us have only held back from doing this out of our
>>belief that goodwill amongst network participants is more important than
>>trying to push some pet feature some of us want.
>>
>> Please stop this negativity - we ALL want the best for Bitcoin and are
>>doing our best, given what we understand and know, to do what¹s right.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:38:39Z

In reply to nevent1q…xe6h
_________________________

📅 Original date posted:2015-06-19
📝 Original message:>When is the right time to allow space pressure to rise that ratio?
>When the subsidy is at 1.5625, for example, it may be too late to

I don¹t believe we have to decide, the miners will do that and are doing
that already.

>start a non-catastrophic transition from subsidies to fees.
>I don't claim to know that, but it's something that worries me.
>No matter how many people say "that's too far away in the future to
>worry about it", I still worry about it and I'm sure more people do.
>What if "when it's time to care about it" we discover that we should
>have started to do things about it long ago to minimize the risks of
>this transition?

Hmmm. What should be the price of an email? How much should DARPA have
charged for using TCP/IP?

I see a lot of well-paid, first-world technologists arguing for commercial
returns on a nacent protocol which could could offer benefits to the
unbanked.
Is that really the vision: to (re)build a de-centralized Paypal with
slightly cheaper fees and cool hooks into off-chain commercial systems
providing profits for the already rich?

>--------------------------------------------------------------------------
>----
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:38:37Z

In reply to nevent1q…ayw8
_________________________

📅 Original date posted:2015-06-19
📝 Original message:Benjamin,

Timeframe for network congestion and users experiencing service
degradation => between now and middle of next year.

Timeframe for transaction fees topping block reward fees => many years in
the future, based on current ratio of block reward to fees.

What is the more pressing requirement now? A working ³fee market² or a
reliable, useful payment network that scales without falling over in the
next 2-3 years.

On 19/6/15 4:53 pm, "Benjamin" <benjamin.l.cordes at gmail.com> wrote:

>Yeah, but increasing block-size is not a longterm solution. Necessary
>higher fees are a logical consequence of lower subsidies. Bitcoin was
>basically free to use at the beginning because miners got paid with
>new coins at the expense of those who already hold coins. Eventually
>there needs to be a mechanism which matches supply and demand.
>
>On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn <mike at plan99.net> wrote:
>>> Or alternatively, fix the reasons why users would have negative
>>> experiences with full blocks
>>
>>
>> It's impossible, Mark. By definition if Bitcoin does not have sufficient
>> capacity for everyone's transactions, some users who were using it will
>>be
>> kicked out to make way for the others. Whether that happens in some
>>kind of
>> stable organised way or (as with the current code) a fairly chaotic way
>> doesn't change the fundamental truth: some users will find their bitcoin
>> savings have become uneconomic to spend.
>>
>> Here's a recent user complaint that provides a preview of coming
>> attractions:
>>
>>
>>https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to
>>_pay_over_10_network_fee/
>>
>>> Hello, I'm just trying to send my small Sarutobi-tips stash (12,159
>>>bits)
>>> onto a paper wallet. When I try to send it, a window pops up stating
>>> "insufficient funds for bitcoin network fee, reduce payment amount by
>>>1,389
>>> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with
>>>$2.50.
>>
>>
>> These sorts of complaints will get more frequent and more extreme in the
>> coming months. I realise that nobody at Blockstream is in the position
>>of
>> running an end user facing service, but many of us are .... and we will
>>be
>> the ones that face the full anger of ordinary users as Bitcoin hits the
>> wall.
>>
>>
>>-------------------------------------------------------------------------
>>-----
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>--------------------------------------------------------------------------
>----
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development