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 ) 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: From: "Raystonn ." To: "Patrick Mccorry \(PGR\)" References: <5574E39C.3090904@thinlink.com>, , <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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 . 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 . 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
> the = attack would be=20 expensive.
 
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.  This gives well-funded private and/or public = entities the=20 means to destroy Bitcoin if they desire.  This is only true after the block size limit was = implemented. =20 Without the block size limit, the spam doesn=E2=80=99t harm = Bitcoin.  It simply=20 enriches miners at the cost of the spammers, which is a nicely = antifragile=20 quality.
 
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.  Whatever fees they are paying, real = transactions will=20 have to pay more to get through.  It can be a net gain depending on = how=20 many miners are participating.
 
 
From: Patrick Mccorry = (PGR)
Sent: Monday, June 08, 2015 2:21 PM
Subject: Re: [Bitcoin-development] New attack identified and = potential solution described: Dropped-transaction spam attack against = the block=20 size limit
 
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.

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.  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.
 
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.
 
If I were to = spam a lot of=20 transactions to fill the memory pool it would cost $120 every 10=20 minutes

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

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.
 
there is no = memory pool=20 cap currently

Real=20 hardware does not have an infinite amount of RAM.  Memory pool = sizes=20 cannot grow unbounded.  Some transactions with insufficient fees = do get=20 dropped today after many hours.
 
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.

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.

Sent from my iPhone

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

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.

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

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

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

there is no memory pool cap=20 currently

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


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

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).

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.

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).

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.

Sent from=20 my iPhone

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

When implemented, the block size limit = was put=20 in place to prevent the
potential for a massive block to be = used as an=20 attack to benefit the miner
of that block.  The theory goes = that such=20 a massive block would enrich its
miner by delaying other miners who are = now=20 busy downloading and validating
that huge block.  The original = miner of=20 that large-block would be free to
continue hashing the next block, = giving it an=20 advantage.

Unfortunately, this block size limit = opened a=20 different attack.  Prior to
the limit, any attempt to spam the = network by=20 anyone other than someone
mining their own transactions would = have been=20 economically unfeasible.  As
every transaction would have a fee, = there=20 would have been a real cost for
every minute of spam.  The end = result=20 would have been a transfer of wealth
from spammer to Bitcoin miners, which = would=20 have harmed the spammers and
encouraged further mining of Bitcoin, = a very=20 antifragile outcome.

But now we have the block size = limit. =20 Things are very different with this
feature in place.  The beginning = of a=20 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=20 enough for transactions to be
dropped from mempools, the vast = majority of=20 spam transaction fees will never
have to be paid.  In fact, as = real users=20 gain in desperation and pay higher
fees to get their transactions through = in a=20 timely manner, the spammers will
adjust their fees to minimize the cost = of the=20 attack and maximize
effectiveness.  Using this = method, they=20 keep their fees at a point that
causes most of the spam transactions = to be=20 dropped without confirmation
(free spam), while forcing a floor for = transaction fees.  Thus, while spam
could be used by attackers to disable = the=20 network entirely, by paying
high-enough fees to actually fill the = blocks=20 with spam, it can also be used
by a single entity to force a = transaction fee=20 floor.  Real users will be
forced to pay a transaction fee higher = than=20 the majority of the spam to get
their transactions confirmed.  So = this is=20 an effective means for a minority
of miners to force higher fees through = spam=20 attacks, even in the face of
benevolent miners who would not = support a=20 higher fee floor by policy.
Miners would simply have no way to fix = this,=20 as they can only put in the
transactions that will fit under the = block=20 size limit.

In the face of such a spam attack, = Bitcoin's=20 credibility and usability would
be severely undermined.  The = block size=20 limit enables this attack, and I now
argue for its removal.  But we = can't just=20 remove it and ignore the problem
that it was intended to address.  = We need=20 a new fix for the large-block
problem described in the first = paragraph that=20 does not suffer from the
dropped-transaction spam-attack = problem that=20 is enabled by the block size
limit today.  My proposal is = likely to be=20 controversial, and I'm very much
open to hearing other better=20 proposals.

Large blocks created by a miner as a = means to=20 spam other miners out of
competition is a problem because = miners do not=20 pay fees for their own
transactions when they mine = them.  They=20 collect the fees they pay.  This
breaks the economic barrier keeping = people=20 from spamming the network, as the
spamming is essentially free.  = The=20 proposed fix is to add a new rule on how
fees are handled.  Some amount of = every=20 fee should be considered as burned
and can never be spent.  I will = propose=20 50% of the fee here, but there may
be better numbers that can be = discovered prior=20 to putting this into place.
If we'd like miners to continue to = collect the=20 same fees after this change,
we can suggest the default fee per = transaction=20 to be doubled.  Half of every
fee would be burned and disappear = forever,=20 effectively distributing the
value of those bitcoins across the = entire=20 money supply.  The other half
would be collected by the miner of the = block=20 as is done today.  This
solution would mean large blocks would = cost a=20 significant number of bitcoin
to create, even when all of the = transactions=20 are created by the miner of
that block.  For this to work, = we'd need=20 to ensure a minimum fee is paid for
most of the transactions in every = block, and=20 the new transaction fee rule is
in place.  Then the block size = limit can=20 be removed.

Raystonn


-----------------------------------------------------= -------------------------
_______________________________________________
Bitcoin-development mailing=20 list
Bitcoin-develop= ment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development=20 =

<= /DIV> ------=_NextPart_000_0230_01D0A1F8.259B9920--