<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:series="http://organizeseries.com/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:rawvoice="http://www.rawvoice.com/rawvoiceRssModule/"
	>
<channel>
	<title>Comments on: Bitcoin Attacks in Plain English</title>
	<atom:link href="http://codinginmysleep.com/bitcoin-attacks-in-plain-english/feed/" rel="self" type="application/rss+xml" />
	<link>http://codinginmysleep.com/bitcoin-attacks-in-plain-english/</link>
	<description></description>
	<lastBuildDate>Thu, 20 Jun 2013 04:10:32 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: AvL</title>
		<link>http://codinginmysleep.com/bitcoin-attacks-in-plain-english/#comment-2974</link>
		<dc:creator>AvL</dc:creator>
		<pubDate>Mon, 08 Oct 2012 10:38:01 +0000</pubDate>
		<guid isPermaLink="false">http://codinginmysleep.com/?p=1396#comment-2974</guid>
		<description><![CDATA[There&#039;s another &quot;attack&quot;, nowadays: As miners become more and more greedy and tend to ignore transactions with &quot;too little&quot; miner fee, all you do is make a transaction with just the right amount of &quot;too little&quot; miner fee. If you spend much too little, then your tx won&#039;t even be propagated, and if you&#039;re &quot;too generous&quot; (in context of the attack), then your tx will just be confirmed. 
 
Needless to say, that this one is easily avertable by waiting for confirmations on receiver&#039;s side, or by tying consequencial outgoing payments to the incoming one, but at least one public bitcoin-related site does not seem to do that, yet. ]]></description>
		<content:encoded><![CDATA[<p>There&#039;s another &quot;attack&quot;, nowadays: As miners become more and more greedy and tend to ignore transactions with &quot;too little&quot; miner fee, all you do is make a transaction with just the right amount of &quot;too little&quot; miner fee. If you spend much too little, then your tx won&#039;t even be propagated, and if you&#039;re &quot;too generous&quot; (in context of the attack), then your tx will just be confirmed. </p>
<p>Needless to say, that this one is easily avertable by waiting for confirmations on receiver&#039;s side, or by tying consequencial outgoing payments to the incoming one, but at least one public bitcoin-related site does not seem to do that, yet. </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bitcoin Attacks in Plain English » Coding In My Sleep &#124; Bitcoin News Bits - CoinBits.com</title>
		<link>http://codinginmysleep.com/bitcoin-attacks-in-plain-english/#comment-2968</link>
		<dc:creator>Bitcoin Attacks in Plain English » Coding In My Sleep &#124; Bitcoin News Bits - CoinBits.com</dc:creator>
		<pubDate>Mon, 08 Oct 2012 07:04:42 +0000</pubDate>
		<guid isPermaLink="false">http://codinginmysleep.com/?p=1396#comment-2968</guid>
		<description><![CDATA[[...] View post: Bitcoin Attacks in Plain English » Coding In My Sleep [...]]]></description>
		<content:encoded><![CDATA[<p>[...] View post: Bitcoin Attacks in Plain English » Coding In My Sleep [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Perry</title>
		<link>http://codinginmysleep.com/bitcoin-attacks-in-plain-english/#comment-2944</link>
		<dc:creator>David Perry</dc:creator>
		<pubDate>Sat, 06 Oct 2012 05:04:30 +0000</pubDate>
		<guid isPermaLink="false">http://codinginmysleep.com/?p=1396#comment-2944</guid>
		<description><![CDATA[Thanks for the tidbit, I had no idea it actually had a name - article updated! ]]></description>
		<content:encoded><![CDATA[<p>Thanks for the tidbit, I had no idea it actually had a name &#8211; article updated! </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bitcoin Attacks in Plain English &#124; Bitcoin News Bits - CoinBits.com</title>
		<link>http://codinginmysleep.com/bitcoin-attacks-in-plain-english/#comment-2943</link>
		<dc:creator>Bitcoin Attacks in Plain English &#124; Bitcoin News Bits - CoinBits.com</dc:creator>
		<pubDate>Sat, 06 Oct 2012 05:03:51 +0000</pubDate>
		<guid isPermaLink="false">http://codinginmysleep.com/?p=1396#comment-2943</guid>
		<description><![CDATA[[...] by  enmaku   link 2 [...]]]></description>
		<content:encoded><![CDATA[<p>[...] by  enmaku   link 2 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: @bitcoinmoney</title>
		<link>http://codinginmysleep.com/bitcoin-attacks-in-plain-english/#comment-2942</link>
		<dc:creator>@bitcoinmoney</dc:creator>
		<pubDate>Sat, 06 Oct 2012 04:22:01 +0000</pubDate>
		<guid isPermaLink="false">http://codinginmysleep.com/?p=1396#comment-2942</guid>
		<description><![CDATA[What you call the Swiss Attack is commonly referred to as the race attack.  The thief broadcasts two separate spend transactions to two separate nodes, hoping the transaction to the merchant does not reach the miners until after the double spend transaction does. 
 
A merchant is very vulnerable to this when operating a node that is misconfigured, and that is the configuration the Swiss chose to use (where they were specifically connected to the merchant&#039;s node).  The proper configuration for a merchant is to not allow incoming transactions and to have an explicit outgoing transaction to a well-connected node. 
 
Additionally, the tip you suggested is good to have as well as being properly configured -- to check unconfirmed transactions with a trusted third party first. 
 
This is a great article, and it has been added it to the Double Spending page on the Bitcoin wiki: 
 
 - &lt;a href=&quot;http://en.bitcoin.it/wiki/Double-spending&quot; rel=&quot;nofollow&quot;&gt;http://en.bitcoin.it/wiki/Double-spending&lt;/a&gt; 
 ]]></description>
		<content:encoded><![CDATA[<p>What you call the Swiss Attack is commonly referred to as the race attack.  The thief broadcasts two separate spend transactions to two separate nodes, hoping the transaction to the merchant does not reach the miners until after the double spend transaction does. </p>
<p>A merchant is very vulnerable to this when operating a node that is misconfigured, and that is the configuration the Swiss chose to use (where they were specifically connected to the merchant&#039;s node).  The proper configuration for a merchant is to not allow incoming transactions and to have an explicit outgoing transaction to a well-connected node. </p>
<p>Additionally, the tip you suggested is good to have as well as being properly configured &#8212; to check unconfirmed transactions with a trusted third party first. </p>
<p>This is a great article, and it has been added it to the Double Spending page on the Bitcoin wiki: </p>
<p> &#8211; <a href="http://en.bitcoin.it/wiki/Double-spending" rel="nofollow">http://en.bitcoin.it/wiki/Double-spending</a> </p>
]]></content:encoded>
	</item>
</channel>
</rss>
