From: Robert Backhaus <robbak@robbak.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] On-going data spam
Date: Tue, 9 Apr 2013 21:34:33 +1000 [thread overview]
Message-ID: <CA+i0-i-4PJkKPm=j0A0vHY8aTuk5p5xx2J-0uJWAKBgdje137w@mail.gmail.com> (raw)
In-Reply-To: <BLU0-SMTP1397D392A87B5A2E21636B8C8C60@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]
The obvious problem is that if you can frame it as a valid address, you can
put what you want there. If you can make it pass the validation, miners
have no way of knowing it's not a valid address.
Of course, there is nothing new about this. I ran strings on the blockchain
and found all sorts of ascii rubbish right from the beginning.
On 9 April 2013 21:17, Jay F <jayf@outlook.com> wrote:
> On 4/9/2013 4:09 AM, Peter Todd wrote:
> > On Tue, Apr 09, 2013 at 12:42:12PM +0200, Mike Hearn wrote:
> >> 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
> > NAK
> >
> > Makes bringing up a new node dependent on other nodes having consistent
> > uptimes, particularly if you are on a low-bandwidth connection.
> >
> >> 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
> > NAK
> >
> > No blacklists
> >
> It depends on how clever the spammers get encoding stuff. If law
> enforcement forensic tools can pull a jpeg header + child porn out of
> the blockchain, then there's a problem that needs mitigation.
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: Type: text/html, Size: 2728 bytes --]
next prev parent reply other threads:[~2013-04-09 12:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 1:22 [Bitcoin-development] On-going data spam Jeff Garzik
2013-04-09 9:28 ` Peter Todd
2013-04-09 10:42 ` Mike Hearn
2013-04-09 11:09 ` Peter Todd
2013-04-09 11:17 ` Jay F
2013-04-09 11:34 ` Robert Backhaus [this message]
2013-04-09 14:14 ` Mike Hearn
2013-04-09 14:39 ` Caleb James DeLisle
2013-04-09 18:56 ` steve
2013-04-09 19:25 ` Gregory Maxwell
2013-04-09 19:43 ` Mike Hearn
2013-04-09 14:50 ` Jeff Garzik
2013-04-09 14:53 ` Mike Hearn
2013-04-09 15:01 ` Jeff Garzik
2013-04-09 17:58 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+i0-i-4PJkKPm=j0A0vHY8aTuk5p5xx2J-0uJWAKBgdje137w@mail.gmail.com' \
--to=robbak@robbak.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox