On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote:
> On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
>
> Note how we can already do this: P2SH uses Hash160, which is
> RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
> provides the full 256 bits, but no-on
On Tue, Apr 9, 2013 at 8:52 PM, Robert Backhaus wrote:
> That sounds workable. I take it that the P2SH address is not stored? I like
> it that this denies the possibility of storing data in the block chain, but
> does not block interesting uses like creating date stamps - You can still
> store the
That sounds workable. I take it that the P2SH address is not stored? I like
it that this denies the possibility of storing data in the block chain, but
does not block interesting uses like creating date stamps - You can still
store the 'fake P2SH' value whose checksum is secured by the blockchain.
On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote:
> On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
>
> Note how we can already do this: P2SH uses Hash160, which is
> RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
> provides the full 256 bits, but no-on
On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
Note how we can already do this: P2SH uses Hash160, which is
RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
provides the full 256 bits, but no-one uses P2SH addresses yet anyway.
This will restrict data stuffing to
(1) Define a new address type, P2SH^2 like P2SH but is instead
H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is
a hash of a P2SH address.
(2) Make a relay rule so that to relay a P2SH^2 you must include
along the inner P2SH address. All nodes can trivially verify it by
hashi
I'm happy to announce the release of bitcoinj 0.8, a Java library for
writing Bitcoin applications. Both simplified and full verification are
supported. BitcoinJ has been used to create everything from end-user wallet
apps to network crawlers to SatoshiDice.
To get bitcoinj 0.8, check out our sour
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
21 matches
Mail list logo
