From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UPdxb-00038r-9d for bitcoin-development@lists.sourceforge.net; Tue, 09 Apr 2013 19:12:03 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mistfpga.net designates 208.91.199.214 as permitted sender) client-ip=208.91.199.214; envelope-from=steve@mistfpga.net; helo=us2.outbound.mailhostbox.com; Received: from us2.outbound.mailhostbox.com ([208.91.199.214]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UPdxZ-0007y5-U8 for bitcoin-development@lists.sourceforge.net; Tue, 09 Apr 2013 19:12:03 +0000 Received: from [192.168.137.230] (unknown [90.206.155.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: steve@mistfpga.net) by us2.outbound.mailhostbox.com (Postfix) with ESMTPSA id E947F8F0767; Tue, 9 Apr 2013 18:56:12 +0000 (GMT) Message-ID: <51646442.6060403@mistfpga.net> Date: Tue, 09 Apr 2013 19:56:02 +0100 From: steve User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Caleb James DeLisle References: <51642835.1040007@lavabit.com> In-Reply-To: <51642835.1040007@lavabit.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A02020A.5164644E.015E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: steve@mistfpga.net X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 208.91.199.211 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [208.91.199.214 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UPdxZ-0007y5-U8 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] On-going data spam 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: Tue, 09 Apr 2013 19:12:03 -0000 On 09/04/2013 15:39, Caleb James DeLisle wrote: > Agreed on the legality aspect but another case which is worth considering is > what anti-virus software might do when certain streams of bytes are sent across > the tcp socket or persisted to disk. Do you mean firewalls or something like snort or other deep packet inspection for the tcp sockets statement? I dont see much of an issue with either. set up your own private testnet and have a play with this http://www.eicar.org/83-0-Anti-Malware-Testfile.html The eicar test virus. > Perhaps worth contacting an AV company and > asking what is the smallest data they have a signature on. I have tried a few ways of getting the eicar string into the blockchain (on a private testnet) and getting it flagged by AV, however it is a bit tricky (the getting it flagged bit). and tbh you would exclude the bitcoin directory and runtime from antivirus scans so i stopped bothering. I am making vague assumptions about using windows with antivirus. (and linux for deep packet inspection, but the idea is the same whatever.) I found no greater attack surface area (in the blockchain) than cookies... thinking about it a bit more, there is a bit more potential as a bounce pad/egg drop location but not much - no heap spraying as such, or d/c tors, or heap header structs, etc. Im sure someone is sure to come up with something very clever tho. just not me. cheers, steve > > Thanks, > Caleb > > > On 04/09/2013 06:42 AM, Mike Hearn wrote: >> OK, as the start of that conversation is now on the list, I might as well post the other thoughts we had. Or at least that I had :) >> >> It's tempting to see this kind of abuse through the lens of fees, because we only have a few hammers and so everything looks like a kind of nail. The problem is the moment you try to define "abuse" economically you end up excluding legitimate and beneficial uses as well. Maybe Peters patch for uneconomical outputs is different because of how it works. But mostly it's true. In this case, fees would never work - Peter said the guy who uploaded Wikileaks paid something like $500 to do it. I guess >> by now it's more like $600-$700. It's hard for regular end users to compete with that kind of wild-eyed dedication to "the cause". >> >> The root problem here is people believe the block chain is a data structure that will live forever and be served by everyone for free, in perpetuity, and is thus the perfect place for "uncensorable" stuff. That's a reasonable assumption given how Bitcoin works today. But there's no reason it will be true in the long run (I know this can be an unpopular viewpoint). >> >> Firstly, legal issues - I think it's very unlikely any sane court would care about illegal stuff in the block chain given you need special tools to extract it (mens rea). Besides, I guess most end users will end up on SPV clients as they mature. So these users already don't have a copy of the entire block chain. I don't worry too much about this. >> >> Secondly, the need to host blocks forever. In future, many (most?) full nodes will be pruning, and won't actually store old blocks at all. They'll just have the utxo database, some undo blocks and some number of old blocks for serving, probably whatever fits in the amount of disk space the user is willing to allocate. But very old blocks will have been deleted. >> >> This leads to the question of what incentives people have to not prune. The obvious incentive is money - charge for access to older parts of the chain. The fewer people that host it, the more you can charge. In the worst case scenario where, you know, only 10 different organizations store a copy of the chain, it might mean that bootstrapping a new node in a trust-less manner is expensive. But I really doubt it'd ever get so few. Serving large static datasets just isn't that expensive. Also, you >> don't actually need to replay from the genesis block to bring up a new code, you can copy the UTXO database from somewhere else. By comparing the databases of lots of different nodes together, the chances of you being in a matrix-like sybil world can be reduced to "beyond reasonable doubt". Maybe nodes would charge for copies of their database too, but ideally there are lots of nodes and so the charge for that should be so close to zero as makes no odds - you can trivially undercut someone by >> buying access to the dataset and then reselling it for a bit less, so the price should converge on the actual cost of providing the service. Which will be very cheap. >> >> There was one last thought I had, which is that if there's a shorter team need to discourage this kind of thing we can use a network/bandwith related hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist can apply to Bloom filtering such that transactions which are known to be "abusive" require you to fully download the block rather than select the transactions with a filter. This means that people >> can still access the data in the chain, but the older it gets the slower and more bandwidth intensive it becomes. Stuffing Wikileaks into the chain sounds good when a 20 line Python script can extract it "instantly". If someone who wants the files has to download gigabytes of padding around it first, suddenly hosting it on a Tor hidden service becomes more attractive. >> >> >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> >> >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >