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
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,
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
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
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
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.
On Tue, Apr 9, 2013 at 10:53 AM, Mike Hearn m...@plan99.net 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
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 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
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle
calebdeli...@lavabit.com 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
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
(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
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
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-one
14 matches
Mail list logo
