GC [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-06-19 to 2015-10-02
💬 Posted a total of 8 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 17:41:57

- reply

📅 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>

2023-06-07 17:37:28

- reply

📅 Original date posted:2015-08-21
📝 Original message:https://www.blocktrail.com/BTC/pools
Limited to 8MB , BIP101 afaik.
On 21/8/15 11:28 am, "odinn via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>This is a simple post.
>
>Who's got visualizations of votes?
>
>One I've seen that I liked was
>
>http://bipsxdevs.azurewebsites.net/
>
>This just covered how developers feel about the various BIPs though.
>
>A visualization I would like to see would include:
>
>pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP sipa
>etc) based on what's published in blocks.
>
>Has anyone hacked up such a thing which would describe miner voting,
>etc. visually in real time?
>
>- --
>http://abis.io ~
>"a protocol concept to enable decentralization
>and expansion of a giving economy, and a new social good"
>https://keybase.io/odinn
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>
>iQEcBAEBAgAGBQJV1prZAAoJEGxwq/inSG8CsN0IAJeHH7iNO7P77pJIDWbRXY1c
>4TUcxeu8Z31OwoR8expv8qLPPGQnO+YbUnwCCSmya9YohA+sDQPoMsbnb7M/k8No
>KCoXr5FRrb67c/8k7zVHoXbwlQ2TWRLABEqHS2wA+UuHEOHQewjkpds5HMLc5rRW
>mGWaa0bkE54XIQjbDgPOrg4yM7DizO45n4ue1yuntKCgL8Few5LC39IFsTxaQHDj
>M8ljBV/XhZ8oJiOje43o+2nxDbmPh9bACt8EqG6Y2jmfY6jDWqDcp+tpvCUmdD1N
>TIBRjSDNFviXQFXLDhtjDCF8QwegA8Zu+YYJMwroRzsLXEdQs1SBK2cOiVE73nA=
>=mSJl
>-----END PGP SIGNATURE-----
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:36:12

- reply

📅 Original date posted:2015-08-18
📝 Original message:Dave,
³ Š highly skilled psychological warfare agents ..²
Paranoia, much?
Or perhaps the ³enemies" of Bitcoin are just sitting patiently, waiting for
it to collapse in time due to its internal contradictions.
From: Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Reply-To: Dave Scotese <dscotese at litmocracy.com>
Date: Tuesday, 18 August 2015 12:37 pm
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Three things:
1) Hostility is generally the result of perceived hostility. If you assume
the best intentions of another person, you will eventually find yourself in
one of two places. Either you will find truth with that person (becuase
they are also seeking it), or you will drive them away (because you will ask
questions that can't be answered by someone trying to deceive).
2) The Wiki says "The current Core developers are Wladimir J. van der Laan,
Gavin Andresen, Jeff Garzik, Gregory Maxwell, and Pieter Wuille." I've seen
no hostility from any of these people.
3) The people who are threatened by Bitcoin aren't stupid enough to ignore
#1. Can anyone imagine that they have not hired highly skilled
psychological warfare agnts to do everything they can to "help" assault what
we decentralization enthusiasts have been working for?
About #2: I'm actually blind to hostility, and that is an intentional
affectation in response to my recognition of #1 and #3 together. If you
feel another person has expressed a bad idea, just ignore it. If you feel
they might be misleading others, post a reply about what you know to clear
up any possible misconceptions. There is no point in identifying
individuals who are being hostile, or pointing out hostility, or being
divisive. Let the rest of us recognize it on our own. Maybe send something
like what I'm writing now.
PS: If anyone is interested in conspiracy theories, I had written this into
my gmail compose window and (presumably) hit a wrong key which caused the
thread to be marked as spam and deleted my whole reply. It hadn't even
saved a draft. I've never seen gmail not save a draft before.
On Mon, Aug 17, 2015 at 9:55 AM, Eric Lombrozo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I should add that in the interest of peace and goodwill, I extend an offer to
> both Mike and Gavin to make their grievances heardŠbut only on the condition
> that we make a good effort to avoid misrepresentation and misreading of the
> other side¹s intentions.
>
>> On Aug 17, 2015, at 9:37 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>>
>>> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Great, so how about you go tell theymos to stop censoring XT posts and
>>> banning the other side on /r/Bitcoin?
>>>
>>> Let users decide what Bitcoin is or isn't.
>>
>> FWIW,
>>
>> I don¹t think what theymos did is very constructive.I understand his
>> positionŠbut it only hurts the cause, unfortunately - the PR battle is not
>> the same thing as a discussion on technical merits. He hurts the PR battle
>> and plays into Mike¹s hand by doing that. The actual underlying issue
>> actually has little to do with block size - it has to do with Mike and Gavin
>> feeling that the core devs are being obstructionist.
>>
>> Regardless of the technical merits of XT, the fact that we¹ve never done a
>> hard fork before, not even for things some other devs have wantedŠand not due
>> to any malice on anyone¹s part but because simply that¹s just the nature of
>> decentralized consensus with well-defined settlement guaranteesŠthis is the
>> problem - Mike and Gavin think they¹re somehow special and their fork should
>> be pushed while the rest of us resist pushing our own controversial pet ideas
>> because we want civility and understand that at this stage in Bitcoin¹s
>> development trying to fork the blockchain over highly divisive issues is
>> counterproductive and destructive.
>>
>> But the fact of the matter is that in the PR battle, arguments against the
>> fork actually play into Mike¹s hand, and that¹s the problem.
>>
>> The whole block size thing is too nuanced and too easily spun simplistically.
>> It¹s too easy to spin resistance to bigger blocks (even though the resistance
>> is actually much more towards untested hardforking mechanisms and serious
>> security concerns) as ³obstructionism² and it¹s too easy to spin bigger
>> blocks as ³scalability² because most of the people can¹t tell the fucking
>> difference.
>>
>> The fact is most of the people don¹t really understand the fundamental issue
>> and are taking sides based on charismatic leadership and authority which is
>> actually entirely counter to the spirit of decentralized consensus. It¹s
>> beyond ironic.
>>
>> If you guys want to win the PR battle, the key is to make it clear that you
>> are not obstructionist and are giving everyone equal treatmentŠBitcoin was
>> designed such that changing the rules is *hard* and this is a feature.
>> Bitcoin simply does not have a reliable and tested hard forking mechanismŠand
>> a hard fork for such a politically divisive issue will almost certainly lead
>> to a lack of cooperation and refusal to work together out of spite. All of us
>> would like to be able to process more transactions on the network. It¹s not a
>> matter of whether we think higher capacity is a bad thing - it¹s more that
>> some of us are concerned that Bitcoin is not sufficiently mature to be able
>> to handle such a schism with so much hostility.
>>
>> Let¹s face it, folks - from a PR standpoint, the block size issue is
>> irrelevant. Nobody really understands it except for a handful of people -
>> I¹ve tried to explain it, I¹ve even written articles about it - but most
>> people just don¹t get it. Most people don¹t really get scalability either -
>> they seem to think that scalability is just doing the same thing you¹ve
>> always done manyfold.
>>
>> Block size is an especially dangerous issue politically because it¹s one of
>> those that requires deep understanding yet superficially sounds really
>> simple. It¹s perfect Dunning-Kruger bait.
>>
>> So let¹s be a little smarter about this.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/> .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
_______________________________________________ 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/20150818/5004de1d/attachment-0001.html>

2023-06-07 17:36:08

- reply

📅 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

2023-06-07 17:35:54

- reply

📅 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

2023-06-07 17:34:35

- reply

📅 Original date posted:2015-08-10
📝 Original message:Following this, Bitcoin and proposed payment networks like LN will be
competing for fees based on duration and cost to process transactions.
If fees on Bitcoin network stay low and zero-conf txns are possible,
competing payment networks will need some very special features to survive
and make money for their investors.
On 10/8/15 10:27 am, "Rune K. Svendsen via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>Nodes in the Lightning network earn fees that wouldn't be there if it
>weren't for the Lightning network. The base Bitcoin layer can't handle
>the transaction throughout that Lightning can, so the Lightning fees were
>never available to Bitcoin miners in the first place.
>
>What Lightning does is raise the value of a transaction on the block
>chain. Imagine you're a Lightning node, and in order to collect your
>fees, that you've earned over the past month, you have to settle on the
>blockchain. If you've earned, say, 0.5 BTC in fees, you can attach a huge
>0.005 BTC fee to the Bitcoin settlement transaction. The miners earn a
>larger fee, and you make sure your transaction gets into the blockchain
>quickly, and you can afford to pay this fee because you've made much more
>on the Lightning transactions you've routed.
>
>/Rune
>
>
>
>> Den 10/08/2015 kl. 00.20 skrev info--- via bitcoin-dev
>><bitcoin-dev at lists.linuxfoundation.org>:
>>
>> Hello all,
>>
>> one argument I often read on this mailing list is that it's essential to
>> reward miners with transaction fees at some point to secure the network.
>>
>> Off-chain transactions, whether it's Lightning or something else,
>> potentially extract fees, which may otherwise be paid to miners, if the
>> transactions were actually on-chain.
>>
>> In this context, wouldn't it be contradictory, maybe even harmful, to
>> aim for an environment, where some/many/most transactions are off-chain?
>>
>> I have not yet seen this conflict addressed in the recent discussions.
>>
>> _______________________________________________
>> 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

- reply

- reply

- reply

- reply

- reply

- reply

📅 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

2023-06-07 15:38:37

- reply

📅 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