<unnamed>

Public Key

npub14jegtpz2t9nfnefqqr0q4te9353e4k4x5y2528qf235ruluzsaes8vk3rk

Profile Code

nprofile1qqs2ev59s399je5eu5sqphs24ujc6gu6m2n2z929rsy4g6p707pgwucpzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakq5vxh3a

Publishing to

nostr.wine

nos.lol

Last Notes

2023-06-07 18:08:42 UTC

- reply

📅 Original date posted:2017-12-14
📝 Original message:On 13 December 2017 at 22:36, David A. Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> - Microbitcoins is not a homonym for any other word in English (and
> probably not in any other language), whereas "bit" and "bits" have
> more than a dozen homonyms in English---some of which are quite common
> in general currency usage, Bitcoin currency usage, or Bitcoin
> technical usage.
Reposting /u/BashCo's post on reddit here, for visibility:
---8<---------------------------------------------------------------
> Before anyone says 'bits' are too confusing because it's a computer science term, here's a list of homonyms [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every day. Homonyms are fine because our brains are able to interpret language based on context, so it's a non-argument. Also, the term 'bits' was used in reference to money long before 'bits and bytes' came along, and even before the metric system itself.
> https://en.wikipedia.org/wiki/Bit_(money)
> https://en.wikipedia.org/wiki/Spanish_colonial_real
> 'Bits' are superior to mBTC partly because we'll need to transition to bits eventually anyways (one transition is easier than two), but more importantly, bits have two decimal places, matching the format of dozens of other major currencies.
> No other currency has 8 decimal places, or even 4 decimal places. Most of them have 2. Dollars and cents, Bits and satoshis.
> If people actually want this to happen, then they need to train their own brains by switching their wallets and exchange settings to bits. The shift will probably happen eventually, although the major Bitcoin denomination probably isn't going anywhere any time soon, even if the majority of people use 'bits' as a matter of habit.
> 99.99 bits is currently equal to $1.63 USD.
---8<---------------------------------------------------------------
>
> - Microbitcoins trains users to understand SI prefixes, allowing them to
> easily migrate from one prefix to the next. This will be important
> when bitcoin prices rise to $10M USD[1] and the bits denomination has
> the same problems the millibitcoin denomination has now, but it's also
> useful in the short term when interacting with users who make very
> large payments (bitcoin-scale) or very small payments
> (nanobitcoin-scale).[2] Maybe a table of scale can emphasize this
> point:
>
> Wrong (IMO): Right (IMO):
> --------------- --------------
> BTC BTC
> mBTC mBTC
> bits µBTC
> nBTC nBTC
>
I wouldn't expect people to type out µBTC. I think the best you can
hope for here is uBTC. As for saying "microbitcoins", I can virtually
guarantee that this will be abbreviated to "microbits" and/or
eventually "bits" anyway. Bits and sats.
> [1] A rise in price to $10M doesn't require huge levels of growth---it
> only requires time under the assumption that a percentage of bitcoins will
> be lost every year due to wallet mishaps, failure to inherit bitcoins,
> and other issues that remove bitcoins from circulation. In other words,
> it's important to remember that Bitcoin is expected to become a
> deflationary currency and plan accordingly.
>
> [2] Although Bitcoin does not currently support committed
> nanobitcoin-scale payments in the block chain, it can be supported in a
> variety of ways by offchain systems---including (it is hypothesized)
> trustless systems based on probabilistic payments.
>
> Thanks,
>
> -Dave
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:42:45 UTC

- reply

📅 Original date posted:2015-10-06
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151006/10d3c219/attachment.html>

2023-06-07 17:35:44 UTC

- reply

📅 Original date posted:2015-08-17
📝 Original message:His account on that website was also compromised.
2015-08-17 21:02 GMT+02:00 Anon Moto via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Satoshi,
>
> As much as I want to believe this is you it's very difficult to ignore the
> fact that Vistomail could have been hacked and I'm currently speaking to a
> troll.
> Can you copy and paste what you wrote above, to
> http://p2pfoundation.ning.com as well, like how you did during the Dorian
> fiasco?
>
>
> Much appreciated.
>
>
> On Sat, Aug 15, 2015 at 10:43 AM, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have been following the recent block size debates through the mailing
>> list. I had hoped the debate would resolve and that a fork proposal would
>> achieve widespread consensus. However with the formal release of Bitcoin
>> XT 0.11A, this looks unlikely to happen, and so I am forced to share my
>> concerns about this very dangerous fork.
>>
>> The developers of this pretender-Bitcoin claim to be following my
>> original vision, but nothing could be further from the truth. When I
>> designed Bitcoin, I designed it in such a way as to make future
>> modifications to the consensus rules difficult without near unanimous
>> agreement. Bitcoin was designed to be protected from the influence of
>> charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or
>> Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have
>> to do it without being forced or pressured into it. By doing a fork in
>> this way, these developers are violating the "original vision" they claim
>> to honour.
>>
>> They use my old writings to make claims about what Bitcoin was supposed
>> to be. However I acknowledge that a lot has changed since that time, and
>> new knowledge has been gained that contradicts some of my early opinions.
>> For example I didn't anticipate pooled mining and its effects on the
>> security of the network. Making Bitcoin a competitive monetary system
>> while also preserving its security properties is not a trivial problem, and
>> we should take more time to come up with a robust solution. I suspect we
>> need a better incentive for users to run nodes instead of relying solely on
>> altruism.
>>
>> If two developers can fork Bitcoin and succeed in redefining what
>> "Bitcoin" is, in the face of widespread technical criticism and through the
>> use of populist tactics, then I will have no choice but to declare Bitcoin
>> a failed project. Bitcoin was meant to be both technically and socially
>> robust. This present situation has been very disappointing to watch unfold.
>>
>> Satoshi Nakamoto
>>
>> _______________________________________________
>> 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/20150817/cb0411d3/attachment-0001.html>

2023-06-07 17:34:49 UTC

- reply

📅 Original date posted:2015-08-14
📝 Original message:In that case it didn't remedy the problem of constantly full blocks, but
got a ton of people on board the bitcoin train in the meanwhile. And with
them more interest, investments, research and ideas.
In the case we increase the limit and no government or banking group
immediately uses up all the space in blocks, it of course would prevent
constantly full blocks for the time being. Bitcoin keeps working reliably,
is fast and cheap -- more users on board the bitcoin train. And as long as
we do not immediately increase it to 1.6GB (something no one is
suggesting), we could still maintain a good level of decentralization,
maybe even increase it together with an increase in users.
Eventually we'll have to deal with the fading subsidy, but there's no
reason to deal with it at this point in time. What we need today is more
users and artifically limiting the blocksize doesn't help with that. At the
very least we should try to incorporate technological growth into bitcoin.
Keep the 2010 1MB limit, but account for "inflation". If you're arguing
that noone can predict the future development of bandwidth, cpu and storage
I'd say it doesn't matter if we are too optimistic, because when we start
seeing that a future doubling of the limit will cause major issues, it will
be easy to find consensus and change the rule accordingly.
2015-08-14 4:26 GMT+02:00 Venzen Khaosan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Geir,
>
> In the scenario below, you argue that the current 1MB limit would lead
> to "constantly full" blocks. If the limit is increased to say 1.6GB
> then a government or banking group may choose to utilize 1.5GB of the
> capacity of each block (and pay fees or not) for their settlement
> network. Then how did upping the blocksize remedy anything? Or is this
> use-case not plausible?
>
> I would like to ask you, or anyone on the list: when we say that
> mining secures the network, what does that mean?
>
>
>
> On 08/14/2015 05:01 AM, Geir Harald Hansen via bitcoin-dev wrote:
> > 3) A few more people begin using bitcoin. Bitcoin buckles and
> > dies.
> >
> > - Something happens a few months from now causing an influx of new
> > users and more transactions. - Blocks are constantly full. - A
> > backlog of transactions keeps growing indefinitely. - At first
> > people say "bitcoin is slow". After a while they say "bitcoin
> > doesn't work". - Changing the hard limit on block size requires a
> > fork and takes too long. - As bitcoin no longer works people stop
> > using it. - Bitcoin lives out the last of its days in the
> > backwaters of the internet with only 5 users. They keep telling
> > people "we increased the block size now". Unfortunately noone is
> > listening anymore. - People laugh at you and say "I told you that
> > buttcoin thing was doomed to fail. After all it wasn't real
> > money."
> >
> > If the hard limit had been increased earlier then mining pools
> > would have been able to react quickly by upping their own soft
> > limit. But this was not the case and so ended Bitcoin.
> >
> > So in summary:
> >
> > By increasing the block size limit you run the risk of: - The
> > transaction fee market takes a little longer to develop. By not
> > increasing the limit you run the risk of: - Bitcoin dies. The end.
> >
> > Transaction fees should not be the main topic of this discussion,
> > and probably not even a part of it at all. That seems outright
> > irresponsible to me.
> >
> > Regards, Geir H. Hansen, Bitminter mining pool
> >
> > On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:
> >> I believe all concerns I've read can be classified in the
> >> following groups:
> >>
> >>> 1) Potential indirect consequence of rising fees.
> >>
> >> - Lowest fee transactions (currently free transactions) will
> >> become more unreliable. - People will migrate to competing
> >> systems (PoW altcoins) with lower fees.
> >>
> >>> 2) Software problem independent of a concrete block size that
> >>> needs to be solved anyway, often specific to Bitcoin Core (ie
> >>> other implementations, say libbitcoin may not necessarily share
> >>> these problems).
> >>
> >> - Bitcoin Core's mempool is unbounded in size and can make the
> >> program crash by using too much memory. - There's no good way to
> >> increase the fee of a transaction that is taking too long to be
> >> mined without the "double spending" transaction with the higher
> >> fee being blocked by most nodes which follow Bitcoin Core's
> >> default policy for conflicting spends replacements (aka "first
> >> seen" replacement policy).
> >>
> >> I have started with the 3 concerns that I read more often, but
> >> please suggest more concerns for these categories and suggest
> >> other categories if you think there's more.
> >> _______________________________________________ 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
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVzVHWAAoJEGwAhlQc8H1myaoH+QFo+eTqPqMps/h/Lt5P4Ker
> UIyCbouatdrRnKqJlpa+dy70+nK+nkz6fizXLC8fuWFDLPQ2uk1cUnp7FPcJ+f6L
> LdGiUktcF/osbA5DW/Xt1DQnClnfbR04oH3+l5ouwhTG2FL8018RQKTAZXYaQafE
> /GUzXBZt+dxpENE2ZE0YDORcm62cysFB8KiqS7NmrNC3sig/Bnw0k8x8y745LcSO
> j/icLJ/zlSVhtceb8AnSg5bC2xhKXrTsGQBfr4foDh78n0+xcbEQO/6xc29rydeB
> l8VwzqCwyFZScM/4lhgYHgEB2KE3MecGNy0vh7jKVqh9lQUMlWtpHRy/Nony5mA=
> =MEzL
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20150814/5899a173/attachment.html>

2023-06-07 15:47:27 UTC

- reply

2023-06-07 15:38:20 UTC

- reply

📅 Original date posted:2015-06-16
📝 Original message:> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
you cannot have it.
Neither do you or anyone else.
> There is protocol for how change is effected in a FOSS project.
And it allows the minority to hold the majority hostage.
> If you take the risks with Mike&GavCoin, that would be fine, but you are
about to take them with community-owned Bitcoin and Other People's Money!
The same can be said about the other camp.
BitcoinXT is not going to fork the chain on a specific date no matter what.
People will be able to vote via block versions and once a sufficient
majority supports the extensions, everyone else will have a grace period to
upgrade. Only after that is a very small minority at risk of losing money.
That being said, I'd rather see a solution that everyone agrees on. My
personal opinion/hope is that Mike and Gavin are just applying pressure
where it's needed. But in the end, they can do whatever they want if they
have the necessary support. Permissionless innovation is one of bitcoins
virtues. In the end, only adoption will decide what bitcoin is and isn't.
2015-06-16 7:18 GMT+02:00 Venzen <venzen at mail.bihthai.net>:
> Mike Hearn,
>
> In the light of your responses to Adam Back's questions, below, I feel
> it is time to speak up because what I now understand, and is implied,
> is that Mike Hearn and Gavin Andresen have planned and deployed the
> infrastructure for a Bitcoin hard-fork and intend to action it despite
> majority opposition. http://xtnodes.com/
>
> I'll try to keep it brief:
>
> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus. Your actions are bad for the
> Bitcoin project and its ideals, disrespectful of your peers and years
> of their passionate hard work, and dangerous for Bitcoin in the
> marketplace and bitcoin in peoples' wallets.
>
> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it. Your hard-fork is tantamount to theft and you and
> your collaborators will effectively ex-communicate yourselves from
> this project and community. It appears that you are consciously trying
> to usurp ownership and maintenance of Bitcoin. As if it is that easy!
> You clearly do not comprehend the array of risks - especially the
> unanticipated ones. As the market saying goes: "If you think
> speculation is easy, it is because you are ignorant about the risks".
> If you take the risks with Mike&GavCoin, that would be fine, but you
> are about to take them with community-owned Bitcoin and Other People's
> Money!
>
> You are causing a lot of stress, unnecessarily, and grave concern
> surrounds your proposed renegade action. You can dissolve the threat:
> those players to whom you have made promises can be appeased and
> eventually get most of what they need from this FOSS project. The
> developers whom you are railroading to get your way, and the way in
> which you are doing it, is about to cause a schism that will expand
> outward from this community.
>
> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>
> If an individual in an objectively agreed-to FOSS-modelled
> collaborative project has the audacity to threaten his peers and the
> world with a unilateral hard-fork despite majority objection and a
> probability distribution that includes terminal risks and unintended
> consequences, then what would an impartial outsider think? Some of
> their thoughts would include that the antagonist could be acting in
> self-interest, or may be a paid actor, or worse, a saboteur. What
> would they advise? Stop that individual, at once!
>
> Bitcoin is a Free and Open Source Software project that serves as
> flagship for the blockchain. It has a payment network but the key
> benefits are censorship resistance and trustless decentralization.
> There is protocol for how change is effected in a FOSS project. For
> the sake of everything that is good and useful in Bitcoin, reconsider
> your dangerous plan and its intended and unintended consequences. Put
> your feet back on the ground, return to the fold and let the
> collaborative FOSS model, and the skills available here, gradually
> scale Bitcoin to your (and all our) grand vision.
>
> Venzen Khaosan
>
>
> On 06/15/2015 04:56 PM, Mike Hearn wrote:
> > Hi Adam,
> >
> > Provisional answers below!
> >
> > - Are you releasing a BIP for that proposal for review?
> >
> >
> > The work splits like this:
> >
> > * Gavin is writing the code and I think a BIP as well
> >
> > * I will review both and mostly delegate to Gavin's good taste
> > around the details, unless there is some very strong disagreement.
> > But that seems unlikely.
> >
> > * I have been handling gitian and the patch rebases, the code
> > signing and so on, so far. I've also been doing some work to setup
> > the basic infrastructure of the project (website etc).
> >
> >
> > - If the reviewers all say NACK will you take on board their
> > suggestions?
> >
> >
> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> > requests aren't scored in any way. The final decision rests with
> > the maintainer as in ~all open source projects.
> >
> >
> >
> > - On the idea of a non-consensus hard-fork at all, I think we can
> > assume you will get a row of NACKs. Can you explain your
> > rationale for going ahead anyway? The risks are well understood
> > and enormous.
> >
> >
> > Yes, I have been working on an article that explains how we got to
> > this point from my perspective. It is quite long, but only because
> > I want it to be readable for people who weren't following the
> > debate.
> >
> > Anyway, I think I've laid out the gist of it over and over again,
> > but to summarise:
> >
> > If Bitcoin runs out of capacity *it will break and many of our
> > users will leave*. That is not an acceptable outcome for myself or
> > the many other wallet, service and merchant developers who have
> > worked for years to build an ecosystem around this protocol.
> >
> >
> >
> > - How do you propose to deal with the extra risks that come from
> > non-consensus hard-forks? Hard-forks themselves are quite risky,
> > but non-consensus ones are extremely dangerous for consensus.
> >
> >
> > The approach is the same for other forks. Voting via block versions
> > and then when there's been >X% for Y time units the 1mb limit is
> > lifted/replaced.
> >
> >
> >
> >
> > - If you're going it alone as it were, are you proposing that you
> > will personally maintain bitcoin-XT? Or do you have a plan to
> > later hand over maintenance to the bitcoin developers?
> >
> >
> > Good question! I have various thoughts on this, but let's wait and
> > see what happens first. Perhaps the new chain won't get the
> > majority on it.
> >
> > In the event that the >1mb chain does eventually win, I would
> > expect Core to apply the patch and rejoin the consensus rather than
> > lose all its users. That would take XT back to being a fairly small
> > patchset to improve the network protocol.
> >
> >
> >
> > - Do you have contingency plans for what to do if the
> > non-consensus hard-fork goes wrong and $3B is lost as a result?
> >
> >
> > Where did you get the $3B figure from? The fork either doesn't
> > happen, or it happens after quite a long period of people knowing
> > it's going to happen - for example because their full node is
> > printing "You need to upgrade" messages due to seeing the larger
> > block version, or because they read the news, or because they heard
> > about it via some other mechanisms.
> >
> > Let me flip the question around. Do you have a contingency plan if
> > Bitcoin runs out of capacity and significant user disruption occurs
> > that results in exodus, followed by fall in BTC price? The only one
> > I've seen is "we can perform an emergency hard fork in a few
> > weeks"!
> >
> >
> >
> > As you can probably tell I think a unilateral fork without
> > wide-scale consensus from the technical and business communities is
> > a deeply inadvisable.
> >
> >
> > Gavin and I have been polling many key players in the ecosystem.
> > The consensus you seek does exist. All wallet developers (except
> > Lawrence), all the major exchanges, all the major payment
> > processors and many of the major mining pools want to see the limit
> > lifted (I haven't been talking to pools, Gavin has).
> >
> > This notion that the change has no consensus is based on you
> > polling the people directly around you and people who like to spend
> > all day on this mailing list. It's not an accurate reflection of
> > the wider Bitcoin community and that is one of the leading reasons
> > there is going to be a fork. A small number of people have been
> > flatly ignoring LOTS of highly technical and passionate developers
> > who have written vast amounts of code, built up the Bitcoin user
> > base, designed hardware and software, and yes built companies.
> >
> > How do you think that makes Bitcoin Core look to the rest of the
> > Bitcoin world? How much confidence does that give people?
> >
> >
> >
> > Of the overall process, I think you can agree we should not be
> > making technical decisions with this level of complexity and
> > consensus risk with financial implications of this magnitude under
> > duress of haste?
> >
> >
> > This debate will never end until a fork makes it irrelevant. There
> > is no process for ending it, despite me begging Wladimir to make
> > one.
> >
> > And there is no haste. We have been debating the block size limit
> > for _years_. We have known it must be lifted for _years_. I kicked
> > off this current round of debates after realising that Wladimir's
> > release timeline wouldn't allow a block size limit to be released
> > before the end of the year. The reason we're talking about it now
> > and not next year is exactly to ensure there is plenty of time.
> >
> >
> >
> >
> > I can sincerely assure you everyone does want to scale bitcoin and
> > shares your long term objective on that
> >
> >
> > I really wish you were right, and I definitely feel you are one of
> > the more reasonable ones Adam. But the overwhelming impression I
> > get from a few others here is that no, they don't want to scale
> > Bitcoin. They already decided it's a technological dead end. They
> > want to kick end users out in order to "incentivise" (force) the
> > creation of some other alternative, claiming that it's still
> > Bitcoin whilst ignoring basic details ... like the fact that no
> > existing wallets or services would work.
> >
> > Scaling Bitcoin can only be achieved by letting it grow, and
> > letting people tackle each bottleneck as it arises at the right
> > times. Not by convincing ourselves that success is failure.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> >
> > _______________________________________________ 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/5f789e97/attachment.html>