path: root/55/7c8055d4693397199aa44438172846907e1c65

Return-Path: <raystonn@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2239C487
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 17:17:50 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from COL004-OMC4S1.hotmail.com (col004-omc4s1.hotmail.com
	[65.55.34.203])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC1FE1C6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 17:17:48 +0000 (UTC)
Received: from COL131-DS18 ([65.55.34.201]) by COL004-OMC4S1.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); 
	Wed, 29 Jul 2015 10:17:48 -0700
X-TMN: [GIeR70jEZji7g+sO/y246CFIPChQgc2n]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS18A37AF6651D961B49AFFFCD8C0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Mike Hearn" <hearn@vinumeris.com>, "Eric Lombrozo" <elombrozo@gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com><CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com><D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
In-Reply-To: <CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
Date: Wed, 29 Jul 2015 10:17:31 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0040_01D0C9E7.C7ADF840"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
X-OriginalArrivalTime: 29 Jul 2015 17:17:48.0354 (UTC)
	FILETIME=[7DE40A20:01D0CA22]
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	FREEMAIL_REPLY, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
	isn'ttemporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2015 17:17:50 -0000

------=_NextPart_000_0040_01D0C9E7.C7ADF840
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Eric, any plans to correct your article at =
https://bitcoinmagazine.com/21377/settling-block-size-debate/?


From: Mike Hearn via bitcoin-dev=20
Sent: Wednesday, July 29, 2015 4:15 AM
To: Eric Lombrozo=20
Cc: Bitcoin Dev=20
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure =
isn'ttemporary

  Irrelevant what term was used - and as brilliant as Satoshi might have =
been at some things, he obviously got this one wrong.

I don't think it's obvious. You may disagree, but don't pretend any of =
this stuff is obvious.

Consider this:  the highest Bitcoin tx fees can possibly go is perhaps a =
little higher than what our competition charges. Too much higher than =
that, and people will just say, you know what .... I'll make a bank =
transfer. It's cheaper and not much slower, sometimes no slower at all.

And now consider that in many parts of the world bank transfers are =
free.

They aren't actually free, of course, but they appear to be free because =
the infrastructure for doing them is cross subsidised by the fees on =
other products and services, or hidden in the prices of goods sold.

So that's a market reality Bitcoin has to handle. It's already more =
expensive than the competition sometimes, but luckily not much more, and =
anyway Bitcoin has some features those other systems lack (and vice =
versa). So it can still be competitive.=20

But your extremely vague notion of a "fee market" neglects to consider =
that it already exists, and it's not a market of "Bitcoin users buying =
space in Bitcoin blocks". It's "users paying to move money".

You can argue with this sort of economic logic if you like, but don't =
claim this stuff is obvious.

  Nobody threatened to start mining huge blocks given how relatively =
inexpensive it was to mine back then?


Not that I recall. It wasn't a response to any actual event, I think, =
but rather a growing realisation that the code was full of DoS attacks.


  Guess what? SPV wallets are still not particularly =
widespread=E2=80=A6and those that are out there are notoriously terrible =
at detecting network forks and making sure they are on the right one.

The most popular mobile wallet (measured by installs) on Android is SPV. =
It has between 500,000 and 1 million installs, whilst Coinbase has not =
yet crossed the 500,000 mark. One of the most popular wallets on iOS is =
SPV. If we had SPV wallets with better user interfaces on desktops, =
they'd be more popular there too (perhaps MultiBit HD can recapture some =
lost ground).

So I would argue that they are in fact very widespread.

Likewise, they are not "notoriously terrible" at detecting chain forks. =
That's a spurious idea that you and Patrick have been pushing lately, =
but they detect them and follow reorgs across them according to the SPV =
algorithm, which is based on most work done. This is exactly what they =
are designed to do.=20

Contrast this with other lightweight wallets which either don't examine =
the block chain or implement the algorithm incorrectly, and I fail to =
see how this can be described as "notoriously terrible".


=20
  I understand that initially it was desirable that transactions be =
free=E2=80=A6but surely even Satoshi understood this couldn=E2=80=99t be =
perpetually self-sustaining=E2=80=A6and that the ability to bid for =
inclusion in blocks would eventually become a crucial component of the =
network. Or were fees just added for decoration?


Fees were added as a way to get money to miners in a fair and =
decentralised way.

Attaching fees directly to all transactions is certainly one way to use =
that, but it's not the only way. As noted above, our competitors prefer =
a combination of price-hiding and cross subsidisation. Both of these can =
be implemented with tx fees, but not necessarily by trying to =
artificially limit supply, which is economically nonsensical.


  We=E2=80=99re already more than six years into this. When were these =
mechanisms going to be developed and tested? After 10 years? 20? Perhaps =
after 1024 =
years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki)


Maybe when there is a need? I already discussed this topic of need here:

https://medium.com/@octskyward/hashing-7d04a887acc8


  Right. Turns out the ledger structure is terrible for constructing the =
kinds of proofs that are most important to validators - i.e. whether an =
output exists, what its script and amounts are, whether it=E2=80=99s =
been spent, etc=E2=80=A6


Validators don't require proofs. That's why they are validators.

I think you're trying to say the block chain doesn't provide the kinds =
of proofs that are most important to lightweight wallets. But I would =
disagree. Even with UTXO commitments, there can still be double spends =
out there in the networks memory pools you are unaware of. Merely being =
presented with a correctly signed transaction doesn't tell you a whole =
lot ..... if you wait for a block, you get the same level of proof =
regardless of whether there are UTXO commitments or not. If you don't =
then you still have to have some trust in your peers that you are seeing =
an accurate and full view of network traffic.

So whilst there are ways to make the protocol incrementally better, when =
you work through the use cases for these sorts of data structures and =
ask "how will this impact the user experience", the primary candidates =
so far don't seem to make much difference.

Remote attestation from secure hardware would make a big difference =
though. Then you could get rid of the waiting times entirely because you =
know the sending wallet won't double spend.


  Yes, let=E2=80=99s wait until things are about to break before even =
beginning to address the issue=E2=80=A6because we can =E2=80=9Ceasily =
create=E2=80=9D anything we haven=E2=80=99t invented yet at the last =
minute.


bitcoinj already has a micropayment channel implementation in it. =
There's a bit of work required to glue everything together, but it's not =
a massive project to start using this to pay nodes for their services.

But it's not needed right now:  serving these clients is so darn cheap. =
And there is plenty of room for optimising things still further!


  I=E2=80=99m one of the very few developers in this space that has =
actually tried *hard* to make your BIP37 work. Amongst the desktop =
wallets listed on bitcoin.org, there are only two that have always =
supported SPV (or at least I think MultiBit has always supported it, =
perhaps I=E2=80=99m wrong). One is MultiBit, the other one is mine. I =
give you credit for your work=E2=80=A6perhaps you could be generous =
enough to extend me some credit too?

MultiBit has always supported it. I apologise for implying you have not =
built a wallet. I think yours is mSIGNA, right? Did it used to be called =
something else? I recognise the website design but must admit, I have =
not heard of mSIGNA before.

Regardless, as a fellow implementor, I would appreciate it more if you =
designed and implemented upgrades, rather than just trashing the work =
done so far as "notoriously terrible", Satoshi as "not a systems =
architect" and so on.



-------------------------------------------------------------------------=
-------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

------=_NextPart_000_0040_01D0C9E7.C7ADF840
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV>Eric, any plans to correct your article at <A=20
title=3Dhttps://bitcoinmagazine.com/21377/settling-block-size-debate/=20
href=3D"https://bitcoinmagazine.com/21377/settling-block-size-debate/">ht=
tps://bitcoinmagazine.com/21377/settling-block-size-debate/</A>?</DIV>
<DIV>&nbsp;</DIV>
<DIV=20
style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: =
"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; =
DISPLAY: inline'>
<DIV style=3D"FONT: 10pt tahoma">
<DIV>&nbsp;</DIV>
<DIV style=3D"BACKGROUND: #f5f5f5">
<DIV style=3D"font-color: black"><B>From:</B> <A=20
title=3Dbitcoin-dev@lists.linuxfoundation.org=20
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">Mike Hearn via=20
bitcoin-dev</A> </DIV>
<DIV><B>Sent:</B> Wednesday, July 29, 2015 4:15 AM</DIV>
<DIV><B>To:</B> <A title=3Delombrozo@gmail.com=20
href=3D"mailto:elombrozo@gmail.com">Eric Lombrozo</A> </DIV>
<DIV><B>Cc:</B> <A title=3Dbitcoin-dev@lists.linuxfoundation.org=20
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">Bitcoin Dev</A> =
</DIV>
<DIV><B>Subject:</B> Re: [bitcoin-dev] Why Satoshi's temporary anti-spam =
measure=20
isn'ttemporary</DIV></DIV></DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV=20
style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: =
"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; =
DISPLAY: inline'>
<DIV dir=3Dltr>
<DIV class=3Dgmail_extra>
<DIV class=3Dgmail_quote>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV>Irrelevant what term was used - and as brilliant as Satoshi might =
have=20
  been at some things, he obviously got this one =
wrong.</DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>I don't think it's obvious. You may disagree, but don't pretend any =
of this=20
stuff is obvious.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Consider this:&nbsp; the highest Bitcoin tx fees can possibly go is =
perhaps=20
a little higher than what our competition charges. Too much higher than =
that,=20
and people will just say, you know what .... I'll make a bank transfer. =
It's=20
cheaper and not much slower, sometimes no slower at all.</DIV>
<DIV>&nbsp;</DIV>
<DIV>And now consider that in many parts of the world bank transfers are =

free.</DIV>
<DIV>&nbsp;</DIV>
<DIV>They aren't actually free, of course, but they <I>appear</I> to be =
free=20
because the infrastructure for doing them is cross subsidised by the =
fees on=20
other products and services, or hidden in the prices of goods =
sold.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So that's a market reality Bitcoin has to handle. It's already more =

expensive than the competition sometimes, but luckily not much more, and =
anyway=20
Bitcoin has some features those other systems lack (and vice versa). So =
it can=20
still be competitive. </DIV>
<DIV>&nbsp;</DIV>
<DIV>But your extremely vague notion of a "fee market" neglects to =
consider that=20
it already exists, and it's not a market of "Bitcoin users buying space =
in=20
Bitcoin blocks". It's "users paying to move money".</DIV>
<DIV>&nbsp;</DIV>
<DIV>You can argue with this sort of economic logic if you like, but =
don't claim=20
this stuff is obvious.</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV><SPAN>
  <DIV>Nobody threatened to start mining huge blocks given how =
relatively=20
  inexpensive it was to mine back =
then?<BR></DIV></SPAN></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>Not that I recall. It wasn't a response to any actual event, I =
think, but=20
rather a growing realisation that the code was full of DoS =
attacks.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV>
  <DIV>Guess what? SPV wallets are still not particularly =
widespread=E2=80=A6and those=20
  that are out there are notoriously terrible at detecting network forks =
and=20
  making sure they are on the right one.</DIV></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>The most popular mobile wallet (measured by installs) on Android is =
SPV. It=20
has between 500,000 and 1 million installs, whilst Coinbase has not yet =
crossed=20
the 500,000 mark. One of the most popular wallets on iOS is SPV. If we =
had SPV=20
wallets with better user interfaces on desktops, they'd be more popular =
there=20
too (perhaps MultiBit HD can recapture some lost ground).</DIV>
<DIV>&nbsp;</DIV>
<DIV>So I would argue that they are in fact very widespread.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Likewise, they are not "notoriously terrible" at detecting chain =
forks.=20
That's a spurious idea that you and Patrick have been pushing lately, =
but they=20
detect them and follow reorgs across them according to the SPV =
algorithm, which=20
is based on most work done. This is exactly what they are designed to =
do. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Contrast this with other lightweight wallets which either don't =
examine the=20
block chain or implement the algorithm incorrectly, and I fail to see =
how this=20
can be described as "notoriously terrible".</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>&nbsp;</DIV>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV>
  <DIV>I understand that initially it was desirable that transactions be =

  free=E2=80=A6but surely even Satoshi understood this couldn=E2=80=99t =
be perpetually=20
  self-sustaining=E2=80=A6and that the ability to bid for inclusion in =
blocks would=20
  eventually become a crucial component of the network. Or were fees =
just added=20
  for decoration?<BR></DIV></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>Fees were added as a way to get money to miners in a fair and =
decentralised=20
way.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Attaching fees directly to all transactions is certainly one way to =
use=20
that, but it's not the only way. As noted above, our competitors prefer =
a=20
combination of price-hiding and cross subsidisation. Both of these can =
be=20
implemented with tx fees, but not necessarily by trying to artificially =
limit=20
supply, which is economically nonsensical.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV>
  <DIV></DIV>
  <DIV>We=E2=80=99re already more than six years into this. When were =
these mechanisms=20
  going to be developed and tested? After 10 years? 20? Perhaps after =
1024=20
  years?(<A=20
  =
href=3D"https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki"=20
  =
target=3D_blank>https://github.com/bitcoin/bips/blob/master/bip-0042.medi=
awiki</A>)<BR></DIV></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>Maybe when there is a need? I already discussed this topic of need=20
here:</DIV>
<DIV>&nbsp;</DIV>
<DIV><A=20
href=3D"https://medium.com/@octskyward/hashing-7d04a887acc8">https://medi=
um.com/@octskyward/hashing-7d04a887acc8</A><BR></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV><SPAN>
  <DIV>Right. Turns out the ledger structure is terrible for =
constructing the=20
  kinds of proofs that are most important to validators - i.e. whether =
an output=20
  exists, what its script and amounts are, whether it=E2=80=99s been =
spent,=20
  etc=E2=80=A6<BR></DIV></SPAN></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>Validators don't require proofs. That's why they are =
validators.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think you're trying to say the block chain doesn't provide the =
kinds of=20
proofs that are most important to lightweight wallets. But I would =
disagree.=20
Even with UTXO commitments, there can still be double spends out there =
in the=20
networks memory pools you are unaware of. Merely being presented with a=20
correctly signed transaction doesn't tell you a whole lot ..... if you =
wait for=20
a block, you get the same level of proof regardless of whether there are =
UTXO=20
commitments or not. If you don't then you still have to have some trust =
in your=20
peers that you are seeing an accurate and full view of network =
traffic.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So whilst there are ways to make the protocol incrementally better, =
when=20
you work through the use cases for these sorts of data structures and =
ask "how=20
will this impact the user experience", the primary candidates so far =
don't seem=20
to make much difference.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Remote attestation from secure hardware would make a big difference =
though.=20
Then you could get rid of the waiting times entirely because you know =
the=20
sending wallet won't double spend.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV><SPAN>
  <DIV></DIV></SPAN>
  <DIV>Yes, let=E2=80=99s wait until things are about to break before =
even beginning to=20
  address the issue=E2=80=A6because we can =E2=80=9Ceasily =
create=E2=80=9D anything we haven=E2=80=99t invented=20
  yet at the last minute.<BR></DIV></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>bitcoinj already has a micropayment channel implementation in it. =
There's a=20
bit of work required to glue everything together, but it's not a massive =
project=20
to start using this to pay nodes for their services.</DIV>
<DIV>&nbsp;</DIV>
<DIV>But it's not needed right now:&nbsp; serving these clients is so =
darn=20
cheap. And there is plenty of room for optimising things still =
further!</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV style=3D"WORD-WRAP: break-word">
  <DIV>
  <DIV></DIV></DIV>
  <DIV>I=E2=80=99m one of the very few developers in this space that has =
actually tried=20
  *hard* to make your BIP37 work. Amongst the desktop wallets listed on =
<A=20
  href=3D"http://bitcoin.org" target=3D_blank>bitcoin.org</A>, there are =
only two=20
  that have always supported SPV (or at least I think MultiBit has =
always=20
  supported it, perhaps I=E2=80=99m wrong). One is MultiBit, the other =
one is mine. I=20
  give you credit for your work=E2=80=A6perhaps you could be generous =
enough to extend=20
  me some credit too?</DIV></DIV></BLOCKQUOTE></DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV class=3Dgmail_extra>MultiBit has always supported it. I apologise =
for=20
implying you have not built a wallet. I think yours is mSIGNA, right? =
Did it=20
used to be called something else? I recognise the website design but =
must admit,=20
I have not heard of mSIGNA before.</DIV>
<DIV class=3Dgmail_extra>&nbsp;</DIV>
<DIV class=3Dgmail_extra>Regardless, as a fellow implementor, I would =
appreciate=20
it more if you designed and implemented upgrades, rather than just =
trashing the=20
work done so far as "notoriously terrible", Satoshi as "not a systems =
architect"=20
and so on.</DIV>
<DIV class=3Dgmail_extra>&nbsp;</DIV></DIV>
<P>
<HR>
_______________________________________________<BR>bitcoin-dev mailing=20
list<BR>bitcoin-dev@lists.linuxfoundation.org<BR>https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev<BR></DIV></DIV></DIV></BODY></HTML=
>

------=_NextPart_000_0040_01D0C9E7.C7ADF840--