AV software changes all the time, I definitely recall cases where AV got
interested in, eg, web browser caches and ended up corrupting things. But
that might be because it knew the files were written by a web browser.
Lightly frying the contents has the disadvantage of no mmap and no
sendfile() in
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle
wrote:
> what anti-virus software might do when certain streams of bytes are sent
> across
> the tcp socket or persisted to disk. Perhaps worth contacting an AV company
> and
> asking what is the smallest data they have a signature on.
I stuff
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 o
On Tue, Apr 09, 2013 at 04:53:47PM +0200, Mike Hearn wrote:
> there's an obvious backwards compatibility problem there. It should
> probably wait until the payment protocol work is done, so the major user of
> micropayments-as-messages can migrate off them.
As I pointed out in my initial post on
On Tue, Apr 9, 2013 at 10:53 AM, Mike Hearn wrote:
>> However, there should be some metrics and heuristics that take care of
>> this problem. Notably the dev consensus (sans you, Mike :)) seems to
>> be that uneconomical outputs should be made non-standard.
> I think that patch is ok as it doesn
> However, there should be some metrics and heuristics that take care of
> this problem. Notably the dev consensus (sans you, Mike :)) seems to
> be that uneconomical outputs should be made non-standard.
I think that patch is ok as it doesn't really have any fixed concept of
what is uneconomical
Well, I'm not fundamentally opposed to a blacklist, but it would have
to be done in a VERY open manner. I do think the community would
agree that storing big data transactions is not the primary purpose of
bitcoin.
However, there should be some metrics and heuristics that take care of
this proble
An approach which I see as workable in the long term is to keep the block
header and an array of bitfields representing each transaction's spent
and unspent outputs. When someone wants to spend money you ask them for the
transaction and ideally you ask them for the transaction and the merkle branch
> Makes bringing up a new node dependent on other nodes having consistent
> uptimes, particularly if you are on a low-bandwidth connection.
>
This is already the case and always has been.
> NAK
>
> No blacklists
If you're volunteering to store and serve the chain no matter what it
contains, in
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 as
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 dep
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
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 m
On Mon, Apr 08, 2013 at 09:22:10PM -0400, Jeff Garzik wrote:
> http://www.reddit.com/r/Bitcoin/comments/1bw9xg/data_in_the_blockchain_wikileaks/
>
> petertodd: yeah somebody put a file upload tool into the chain
> and then tried to upload the entire amibios source code to it. stupid.
> someone t
http://www.reddit.com/r/Bitcoin/comments/1bw9xg/data_in_the_blockchain_wikileaks/
petertodd: yeah somebody put a file upload tool into the chain
and then tried to upload the entire amibios source code to it. stupid.
someone thinks it's a lot more important than it really is
TD: and 2.5MB of wik
15 matches
Mail list logo
