path: root/c9/7dac24918e074146895697ec7d07cd031dfd55

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <raystonn@hotmail.com>) id 1Z24gP-000489-2z
	for bitcoin-development@lists.sourceforge.net;
	Mon, 08 Jun 2015 21:34:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of hotmail.com
	designates 65.55.34.209 as permitted sender)
	client-ip=65.55.34.209; envelope-from=raystonn@hotmail.com;
	helo=COL004-OMC4S7.hotmail.com; 
Received: from col004-omc4s7.hotmail.com ([65.55.34.209])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Z24gM-0004h6-Ef
	for bitcoin-development@lists.sourceforge.net;
	Mon, 08 Jun 2015 21:34:13 +0000
Received: from COL131-DS6 ([65.55.34.200]) by COL004-OMC4S7.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Mon, 8 Jun 2015 14:34:04 -0700
X-TMN: [x2EThDdvhF7KVeRAY5aOJ9D+jgRbne9a]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS61BB9B5776DE65077ED0ACDBF0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Patrick Mccorry \(PGR\)" <patrick.mccorry@newcastle.ac.uk>
References: <5574E39C.3090904@thinlink.com>,
	<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
	<AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>,
	<COL131-DS2729F02884BC43E54C8D63CDBF0@phx.gbl>
	<7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk>
In-Reply-To: <7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk>
Date: Mon, 8 Jun 2015 14:33:54 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0230_01D0A1F8.259B9920"
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: 08 Jun 2015 21:34:04.0775 (UTC)
	FILETIME=[D7E26F70:01D0A232]
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(raystonn[at]hotmail.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.55.34.209 listed in list.dnswl.org]
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z24gM-0004h6-Ef
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New attack identified and potential
	solution	described: Dropped-transaction spam attack against
	the block	size limit
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2015 21:34:13 -0000

------=_NextPart_000_0230_01D0A1F8.259B9920
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> the attack would be expensive.

For attacks being waged to destroy Bitcoin by filling all blocks with =
spam transactions, the attack succeeds when the attacker is well funded. =
 This gives well-funded private and/or public entities the means to =
destroy Bitcoin if they desire.  This is only true after the block size =
limit was implemented.  Without the block size limit, the spam =
doesn=E2=80=99t harm Bitcoin.  It simply enriches miners at the cost of =
the spammers, which is a nicely antifragile quality.

For attacks being waged to push up minimum fees for the benefit of =
miners, by filling the mempool with enough spam transactions with the =
floor fee to cover a new block every time another block is discovered, =
they stand to gain.  Whatever fees they are paying, real transactions =
will have to pay more to get through.  It can be a net gain depending on =
how many miners are participating.


From: Patrick Mccorry (PGR)=20
Sent: Monday, June 08, 2015 2:21 PM
To: Raystonn .=20
Cc: Bitcoin Dev=20
Subject: Re: [Bitcoin-development] New attack identified and potential =
solution described: Dropped-transaction spam attack against the block =
size limit

    If I were a miner under this attack, I would just use the spam to =
fill up blocks alongside normal transactions maximising my profit.

  You are assuming here that you can identify which transactions are =
spam, and which are not, and then segregate the spam into a separate =
channels of transactions for inclusion on a 50/50 basis alongside other =
transactions. There is no guarantee you will be able to identify those =
transactions. Sure, if you can do that, then the easy fix is just to put =
them into a lower class channel of transactions that guarantee no =
pressure on the non-spam transactions.  But it's just not possible to do =
this in any meaningful way. If you wanted to try, it would certainly add =
quite a bit of cost and complexity on the miner's side, and you aren't =
going to get anything other than the simple spam that comes from the =
same set of addresses.

Well it depends how the transactions spam - if you do a huge link of =
transactions (one after another, with the total bitcoins "sent" being =
reduced by a fee each time) this is easily identifiable - if you were to =
do it using unlinked transactions then this would require 2x the setup =
(do a lot of mixing to get 1 million unlinked outputs and then commence =
attack) which doubles the cost of the attack.=20

    If I were to spam a lot of transactions to fill the memory pool it =
would cost $120 every 10 minutes

  You need to account for the transactions coming from real users.  =
Every real transaction is approximately one less spam transaction you =
need to fill the blocks.


I was suggesting the cost of an adversary to send the spam - if he did =
manage to fill the entire block each time that's the maximum charge. Of =
course the costs get spread out if normal transactions are included.=20

    there is no memory pool cap currently

  Real hardware does not have an infinite amount of RAM.  Memory pool =
sizes cannot grow unbounded.  Some transactions with insufficient fees =
do get dropped today after many hours.

That's true that's why I used 250mb as an example to cost $30k. Cheap =
laptops today (around =C2=A3300) come with 6gb ram - so the attack would =
be expensive.=20

I do doubt the miners codes probably are not prepared for an attack of =
this type - but it is really expensive to pull off from what I can see.=20

Sent from my iPhone

On 8 Jun 2015, at 22:14, Raystonn . <raystonn@hotmail.com> wrote:


    If I were a miner under this attack, I would just use the spam to =
fill up blocks alongside normal transactions maximising my profit.


  You are assuming here that you can identify which transactions are =
spam, and which are not, and then segregate the spam into a separate =
channels of transactions for inclusion on a 50/50 basis alongside other =
transactions. There is no guarantee you will be able to identify those =
transactions. Sure, if you can do that, then the easy fix is just to put =
them into a lower class channel of transactions that guarantee no =
pressure on the non-spam transactions.  But it's just not possible to do =
this in any meaningful way. If you wanted to try, it would certainly add =
quite a bit of cost and complexity on the miner's side, and you aren't =
going to get anything other than the simple spam that comes from the =
same set of addresses.


    If I were to spam a lot of transactions to fill the memory pool it =
would cost $120 every 10 minutes


  You need to account for the transactions coming from real users.  =
Every real transaction is approximately one less spam transaction you =
need to fill the blocks.


    there is no memory pool cap currently


  Real hardware does not have an infinite amount of RAM.  Memory pool =
sizes cannot grow unbounded.  Some transactions with insufficient fees =
do get dropped today after many hours.


  -----Original Message----- From: Patrick Mccorry (PGR)
  Sent: Monday, June 08, 2015 1:28 PM
  To: Raystonn .
  Cc: Bitcoin Dev
  Subject: Re: [Bitcoin-development] New attack identified and potential =
solution described: Dropped-transaction spam attack against the block =
size limit

  Please correct me if I'm wrong (hopefully understood it). I don't =
think normal users would need to pay a higher fee - as miners can just =
ignore the spam (since they will all be linked).

  If I were to spam a lot of transactions to fill the memory pool it =
would cost $120 every 10 minutes (assuming 4,000 tx can fit inside a =
block and 3 cents per transaction), anything exceeding that may be =
considered "spam" - although I don't know if it would be "free" as the =
miner will eventually claim all the fees, delayed payment is probably a =
better way to describe it. IIRC, there is no memory pool cap currently. =
To spam 1 million transactions would cost $30k which would take up =
approx 250 blocks (around 250mb) which is around 42 hours to process. I =
think the memory pool can handle this data today (someone more =
knowledgeable can check this for me) - so the attack is v.expensive to =
carry out.

  A good way to prevent this spamming the memory pool is to only accept =
up to a 'x' length of 0-confirmed transactions to make it more difficult =
to pull off (not impossible).

  If I were a miner under this attack, I would just use the spam to fill =
up blocks alongside normal transactions maximising my profit.

  Sent from my iPhone


    On 8 Jun 2015, at 21:09, Raystonn . <raystonn@hotmail.com> wrote:



    When implemented, the block size limit was put in place to prevent =
the

    potential for a massive block to be used as an attack to benefit the =
miner

    of that block.  The theory goes that such a massive block would =
enrich its

    miner by delaying other miners who are now busy downloading and =
validating

    that huge block.  The original miner of that large-block would be =
free to

    continue hashing the next block, giving it an advantage.



    Unfortunately, this block size limit opened a different attack.  =
Prior to

    the limit, any attempt to spam the network by anyone other than =
someone

    mining their own transactions would have been economically =
unfeasible.  As

    every transaction would have a fee, there would have been a real =
cost for

    every minute of spam.  The end result would have been a transfer of =
wealth

    from spammer to Bitcoin miners, which would have harmed the spammers =
and

    encouraged further mining of Bitcoin, a very antifragile outcome.



    But now we have the block size limit.  Things are very different =
with this

    feature in place.  The beginning of a spam attack on the Bitcoin =
network

    will incur transaction fees, just like before.  But if spam =
continues at a

    rate exceeding the block size limit long enough for transactions to =
be

    dropped from mempools, the vast majority of spam transaction fees =
will never

    have to be paid.  In fact, as real users gain in desperation and pay =
higher

    fees to get their transactions through in a timely manner, the =
spammers will

    adjust their fees to minimize the cost of the attack and maximize

    effectiveness.  Using this method, they keep their fees at a point =
that

    causes most of the spam transactions to be dropped without =
confirmation

    (free spam), while forcing a floor for transaction fees.  Thus, =
while spam

    could be used by attackers to disable the network entirely, by =
paying

    high-enough fees to actually fill the blocks with spam, it can also =
be used

    by a single entity to force a transaction fee floor.  Real users =
will be

    forced to pay a transaction fee higher than the majority of the spam =
to get

    their transactions confirmed.  So this is an effective means for a =
minority

    of miners to force higher fees through spam attacks, even in the =
face of

    benevolent miners who would not support a higher fee floor by =
policy.

    Miners would simply have no way to fix this, as they can only put in =
the

    transactions that will fit under the block size limit.



    In the face of such a spam attack, Bitcoin's credibility and =
usability would

    be severely undermined.  The block size limit enables this attack, =
and I now

    argue for its removal.  But we can't just remove it and ignore the =
problem

    that it was intended to address.  We need a new fix for the =
large-block

    problem described in the first paragraph that does not suffer from =
the

    dropped-transaction spam-attack problem that is enabled by the block =
size

    limit today.  My proposal is likely to be controversial, and I'm =
very much

    open to hearing other better proposals.



    Large blocks created by a miner as a means to spam other miners out =
of

    competition is a problem because miners do not pay fees for their =
own

    transactions when they mine them.  They collect the fees they pay.  =
This

    breaks the economic barrier keeping people from spamming the =
network, as the

    spamming is essentially free.  The proposed fix is to add a new rule =
on how

    fees are handled.  Some amount of every fee should be considered as =
burned

    and can never be spent.  I will propose 50% of the fee here, but =
there may

    be better numbers that can be discovered prior to putting this into =
place.

    If we'd like miners to continue to collect the same fees after this =
change,

    we can suggest the default fee per transaction to be doubled.  Half =
of every

    fee would be burned and disappear forever, effectively distributing =
the

    value of those bitcoins across the entire money supply.  The other =
half

    would be collected by the miner of the block as is done today.  This

    solution would mean large blocks would cost a significant number of =
bitcoin

    to create, even when all of the transactions are created by the =
miner of

    that block.  For this to work, we'd need to ensure a minimum fee is =
paid for

    most of the transactions in every block, and the new transaction fee =
rule is

    in place.  Then the block size limit can be removed.



    Raystonn





    =
-------------------------------------------------------------------------=
-----

    _______________________________________________

    Bitcoin-development mailing list

    Bitcoin-development@lists.sourceforge.net

    https://lists.sourceforge.net/lists/listinfo/bitcoin-development=20



------=_NextPart_000_0230_01D0A1F8.259B9920
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV>&gt; <FONT face=3DCalibri><FONT style=3D"FONT-SIZE: 12pt">the =
attack would be=20
expensive.</FONT></FONT></DIV>
<DIV><FONT size=3D3 face=3DCalibri></FONT>&nbsp;</DIV>
<DIV><FONT size=3D3 face=3DCalibri>For attacks being waged to destroy =
Bitcoin by=20
filling all blocks with spam transactions, the attack succeeds when the =
attacker=20
is well funded.&nbsp; This gives well-funded private and/or public =
entities the=20
means to destroy Bitcoin if they desire.&nbsp; </FONT><FONT size=3D3=20
face=3DCalibri>This is only true after the block size limit was =
implemented.&nbsp;=20
Without the block size limit, the spam doesn=E2=80=99t harm =
Bitcoin.&nbsp; It simply=20
enriches miners at the cost of the spammers, which is a nicely =
antifragile=20
quality.</FONT></DIV>
<DIV><FONT size=3D3 face=3DCalibri></FONT>&nbsp;</DIV>
<DIV><FONT size=3D3 face=3DCalibri>For attacks being waged to push up =
minimum fees=20
for the benefit of miners, by filling the mempool with enough spam =
transactions=20
with the floor fee to cover a new block every time another block is =
discovered,=20
they stand to gain.&nbsp; Whatever fees they are paying, real =
transactions will=20
have to pay more to get through.&nbsp; It can be a net gain depending on =
how=20
many miners are participating.</FONT></DIV>
<DIV><FONT size=3D3 face=3DCalibri></FONT>&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=3Dpatrick.mccorry@newcastle.ac.uk=20
href=3D"mailto:patrick.mccorry@newcastle.ac.uk">Patrick Mccorry =
(PGR)</A> </DIV>
<DIV><B>Sent:</B> Monday, June 08, 2015 2:21 PM</DIV>
<DIV><B>To:</B> <A title=3Draystonn@hotmail.com=20
href=3D"mailto:raystonn@hotmail.com">Raystonn .</A> </DIV>
<DIV><B>Cc:</B> <A title=3Dbitcoin-development@lists.sourceforge.net=20
href=3D"mailto:bitcoin-development@lists.sourceforge.net">Bitcoin =
Dev</A> </DIV>
<DIV><B>Subject:</B> Re: [Bitcoin-development] New attack identified and =

potential solution described: Dropped-transaction spam attack against =
the block=20
size limit</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>
<BLOCKQUOTE type=3D"cite">
  <BLOCKQUOTE type=3D"cite"><FONT color=3D#000000><SPAN>If I were a =
miner under=20
    this attack, I would just use the spam to fill up blocks alongside =
normal=20
    transactions maximising my profit.</SPAN></FONT></BLOCKQUOTE><FONT=20
  color=3D#000000><SPAN><BR>You are assuming here that you can identify =
which=20
  transactions are spam, and which are not, and then segregate the spam =
into a=20
  separate channels of transactions for inclusion on a 50/50 basis =
alongside=20
  other transactions. There is no guarantee you will be able to identify =
those=20
  transactions. Sure, if you can do that, then the easy fix is just to =
put them=20
  into a lower class channel of transactions that guarantee no pressure =
on the=20
  non-spam transactions.&nbsp; But it's just not possible to do this in =
any=20
  meaningful way. If you wanted to try, it would certainly add quite a =
bit of=20
  cost and complexity on the miner's side, and you aren't going to get =
anything=20
  other than the simple spam that comes from the same set of=20
  addresses.</SPAN></FONT></BLOCKQUOTE>
<DIV>&nbsp;</DIV>Well it depends how the transactions spam - if you do a =
huge=20
link of transactions (one after another, with the total bitcoins "sent" =
being=20
reduced by a fee each time) this is easily identifiable - if you were to =
do it=20
using unlinked transactions then this would require 2x the setup (do a =
lot of=20
mixing to get 1 million unlinked outputs and then commence attack) which =
doubles=20
the cost of the attack. </DIV>
<DIV>&nbsp;</DIV>
<DIV>
<BLOCKQUOTE type=3D"cite">
  <BLOCKQUOTE type=3D"cite"><FONT color=3D#000000><SPAN>If I were to =
spam a lot of=20
    transactions to fill the memory pool it would cost $120 every 10=20
    minutes</SPAN></FONT></BLOCKQUOTE><FONT =
color=3D#000000><SPAN><BR>You need to=20
  account for the transactions coming from real users.&nbsp; Every real=20
  transaction is approximately one less spam transaction you need to =
fill the=20
  blocks.</SPAN></FONT></BLOCKQUOTE><BR></DIV>
<DIV>I was suggesting the cost of an adversary to send the spam - if he =
did=20
manage to fill the entire block each time that's the maximum charge. Of =
course=20
the costs get spread out if normal transactions are included. </DIV>
<DIV>&nbsp;</DIV>
<DIV>
<BLOCKQUOTE type=3D"cite">
  <BLOCKQUOTE type=3D"cite"><FONT color=3D#000000><SPAN>there is no =
memory pool=20
    cap currently</SPAN></FONT></BLOCKQUOTE><FONT =
color=3D#000000><SPAN><BR>Real=20
  hardware does not have an infinite amount of RAM.&nbsp; Memory pool =
sizes=20
  cannot grow unbounded.&nbsp; Some transactions with insufficient fees =
do get=20
  dropped today after many hours.</SPAN></FONT></BLOCKQUOTE>
<DIV>&nbsp;</DIV>That's true that's why I used 250mb as an example to =
cost $30k.=20
Cheap laptops today (around =C2=A3300) come with 6gb ram - so the attack =
would be=20
expensive. <BR><BR>I do doubt the miners codes probably are not prepared =
for an=20
attack of this type - but it is really expensive to pull off from what I =
can=20
see. <BR><BR>Sent from my iPhone</DIV>
<DIV><BR>On 8 Jun 2015, at 22:14, Raystonn . &lt;<A=20
href=3D"mailto:raystonn@hotmail.com">raystonn@hotmail.com</A>&gt;=20
wrote:<BR><BR></DIV>
<BLOCKQUOTE type=3D"cite">
  <DIV>
  <BLOCKQUOTE type=3D"cite"><SPAN>If I were a miner under this attack, I =
would=20
    just use the spam to fill up blocks alongside normal transactions =
maximising=20
    my profit.</SPAN><BR></BLOCKQUOTE><SPAN></SPAN><BR><SPAN>You are =
assuming here=20
  that you can identify which transactions are spam, and which are not, =
and then=20
  segregate the spam into a separate channels of transactions for =
inclusion on a=20
  50/50 basis alongside other transactions. There is no guarantee you =
will be=20
  able to identify those transactions. Sure, if you can do that, then =
the easy=20
  fix is just to put them into a lower class channel of transactions =
that=20
  guarantee no pressure on the non-spam transactions.&nbsp; But it's =
just not=20
  possible to do this in any meaningful way. If you wanted to try, it =
would=20
  certainly add quite a bit of cost and complexity on the miner's side, =
and you=20
  aren't going to get anything other than the simple spam that comes =
from the=20
  same set of addresses.</SPAN><BR><SPAN></SPAN><BR>
  <BLOCKQUOTE type=3D"cite"><SPAN>If I were to spam a lot of =
transactions to=20
    fill the memory pool it would cost $120 every 10=20
  minutes</SPAN><BR></BLOCKQUOTE><SPAN></SPAN><BR><SPAN>You need to =
account for=20
  the transactions coming from real users.&nbsp; Every real transaction =
is=20
  approximately one less spam transaction you need to fill the=20
  blocks.</SPAN><BR><SPAN></SPAN><BR>
  <BLOCKQUOTE type=3D"cite"><SPAN>there is no memory pool cap=20
    currently</SPAN><BR></BLOCKQUOTE><SPAN></SPAN><BR><SPAN>Real =
hardware does not=20
  have an infinite amount of RAM.&nbsp; Memory pool sizes cannot grow=20
  unbounded.&nbsp; Some transactions with insufficient fees do get =
dropped today=20
  after many=20
  hours.</SPAN><BR><SPAN></SPAN><BR><SPAN></SPAN><BR><SPAN>-----Original =

  Message----- From: Patrick Mccorry (PGR)</SPAN><BR><SPAN>Sent: Monday, =
June=20
  08, 2015 1:28 PM</SPAN><BR><SPAN>To: Raystonn .</SPAN><BR><SPAN>Cc: =
Bitcoin=20
  Dev</SPAN><BR><SPAN>Subject: Re: [Bitcoin-development] New attack =
identified=20
  and potential solution described: Dropped-transaction spam attack =
against the=20
  block size limit</SPAN><BR><SPAN></SPAN><BR><SPAN>Please correct me if =
I'm=20
  wrong (hopefully understood it). I don't think normal users would need =
to pay=20
  a higher fee - as miners can just ignore the spam (since they will all =
be=20
  linked).</SPAN><BR><SPAN></SPAN><BR><SPAN>If I were to spam a lot of=20
  transactions to fill the memory pool it would cost $120 every 10 =
minutes=20
  (assuming 4,000 tx can fit inside a block and 3 cents per =
transaction),=20
  anything exceeding that may be considered "spam" - although I don't =
know if it=20
  would be "free" as the miner will eventually claim all the fees, =
delayed=20
  payment is probably a better way to describe it. IIRC, there is no =
memory pool=20
  cap currently. To spam 1 million transactions would cost $30k which =
would take=20
  up approx 250 blocks (around 250mb) which is around 42 hours to =
process. I=20
  think the memory pool can handle this data today (someone more =
knowledgeable=20
  can check this for me) - so the attack is v.expensive to carry=20
  out.</SPAN><BR><SPAN></SPAN><BR><SPAN>A good way to prevent this =
spamming the=20
  memory pool is to only accept up to a 'x' length of 0-confirmed =
transactions=20
  to make it more difficult to pull off (not=20
  impossible).</SPAN><BR><SPAN></SPAN><BR><SPAN>If I were a miner under =
this=20
  attack, I would just use the spam to fill up blocks alongside normal=20
  transactions maximising my =
profit.</SPAN><BR><SPAN></SPAN><BR><SPAN>Sent from=20
  my iPhone</SPAN><BR><SPAN></SPAN><BR>
  <BLOCKQUOTE type=3D"cite"><SPAN>On 8 Jun 2015, at 21:09, Raystonn . =
&lt;<A=20
    href=3D"mailto:raystonn@hotmail.com">raystonn@hotmail.com</A>&gt;=20
    wrote:</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>When implemented, the block size limit =
was put=20
    in place to prevent the</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>potential for a massive block to be =
used as an=20
    attack to benefit the miner</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>of that block.&nbsp; The theory goes =
that such=20
    a massive block would enrich its</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>miner by delaying other miners who are =
now=20
    busy downloading and validating</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>that huge block.&nbsp; The original =
miner of=20
    that large-block would be free to</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>continue hashing the next block, =
giving it an=20
    advantage.</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>Unfortunately, this block size limit =
opened a=20
    different attack.&nbsp; Prior to</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>the limit, any attempt to spam the =
network by=20
    anyone other than someone</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>mining their own transactions would =
have been=20
    economically unfeasible.&nbsp; As</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>every transaction would have a fee, =
there=20
    would have been a real cost for</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>every minute of spam.&nbsp; The end =
result=20
    would have been a transfer of wealth</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>from spammer to Bitcoin miners, which =
would=20
    have harmed the spammers and</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>encouraged further mining of Bitcoin, =
a very=20
    antifragile outcome.</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>But now we have the block size =
limit.&nbsp;=20
    Things are very different with this</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>feature in place.&nbsp; The beginning =
of a=20
    spam attack on the Bitcoin network</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>will incur transaction fees, just like =

    before.&nbsp; But if spam continues at a</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>rate exceeding the block size limit =
long=20
    enough for transactions to be</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>dropped from mempools, the vast =
majority of=20
    spam transaction fees will never</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>have to be paid.&nbsp; In fact, as =
real users=20
    gain in desperation and pay higher</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>fees to get their transactions through =
in a=20
    timely manner, the spammers will</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>adjust their fees to minimize the cost =
of the=20
    attack and maximize</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>effectiveness.&nbsp; Using this =
method, they=20
    keep their fees at a point that</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>causes most of the spam transactions =
to be=20
    dropped without confirmation</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>(free spam), while forcing a floor for =

    transaction fees.&nbsp; Thus, while spam</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>could be used by attackers to disable =
the=20
    network entirely, by paying</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>high-enough fees to actually fill the =
blocks=20
    with spam, it can also be used</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>by a single entity to force a =
transaction fee=20
    floor.&nbsp; Real users will be</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>forced to pay a transaction fee higher =
than=20
    the majority of the spam to get</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>their transactions confirmed.&nbsp; So =
this is=20
    an effective means for a minority</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>of miners to force higher fees through =
spam=20
    attacks, even in the face of</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>benevolent miners who would not =
support a=20
    higher fee floor by policy.</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>Miners would simply have no way to fix =
this,=20
    as they can only put in the</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>transactions that will fit under the =
block=20
    size limit.</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>In the face of such a spam attack, =
Bitcoin's=20
    credibility and usability would</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>be severely undermined.&nbsp; The =
block size=20
    limit enables this attack, and I now</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>argue for its removal.&nbsp; But we =
can't just=20
    remove it and ignore the problem</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>that it was intended to address.&nbsp; =
We need=20
    a new fix for the large-block</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>problem described in the first =
paragraph that=20
    does not suffer from the</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>dropped-transaction spam-attack =
problem that=20
    is enabled by the block size</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>limit today.&nbsp; My proposal is =
likely to be=20
    controversial, and I'm very much</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>open to hearing other better=20
    proposals.</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>Large blocks created by a miner as a =
means to=20
    spam other miners out of</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>competition is a problem because =
miners do not=20
    pay fees for their own</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>transactions when they mine =
them.&nbsp; They=20
    collect the fees they pay.&nbsp; This</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>breaks the economic barrier keeping =
people=20
    from spamming the network, as the</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>spamming is essentially free.&nbsp; =
The=20
    proposed fix is to add a new rule on how</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>fees are handled.&nbsp; Some amount of =
every=20
    fee should be considered as burned</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>and can never be spent.&nbsp; I will =
propose=20
    50% of the fee here, but there may</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>be better numbers that can be =
discovered prior=20
    to putting this into place.</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>If we'd like miners to continue to =
collect the=20
    same fees after this change,</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>we can suggest the default fee per =
transaction=20
    to be doubled.&nbsp; Half of every</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>fee would be burned and disappear =
forever,=20
    effectively distributing the</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>value of those bitcoins across the =
entire=20
    money supply.&nbsp; The other half</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>would be collected by the miner of the =
block=20
    as is done today.&nbsp; This</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>solution would mean large blocks would =
cost a=20
    significant number of bitcoin</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>to create, even when all of the =
transactions=20
    are created by the miner of</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>that block.&nbsp; For this to work, =
we'd need=20
    to ensure a minimum fee is paid for</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>most of the transactions in every =
block, and=20
    the new transaction fee rule is</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>in place.&nbsp; Then the block size =
limit can=20
    be removed.</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>Raystonn</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE=20
    =
type=3D"cite"><SPAN>-----------------------------------------------------=
-------------------------</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE=20
    =
type=3D"cite"><SPAN>_______________________________________________</SPAN=
><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN>Bitcoin-development mailing=20
  list</SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN><A=20
    =
href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develop=
ment@lists.sourceforge.net</A></SPAN><BR></BLOCKQUOTE>
  <BLOCKQUOTE type=3D"cite"><SPAN><A=20
    =
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development"=
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development</A>=20
    =
</SPAN><BR></BLOCKQUOTE><SPAN></SPAN><BR></DIV></BLOCKQUOTE></DIV></DIV><=
/DIV></BODY></HTML>

------=_NextPart_000_0230_01D0A1F8.259B9920--