Hey Peter, thanks for your experienced feedback.
On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote:
Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
protocols; you haven't taken into account the needs of those protocols.
For BIP's it's better to stick
There was this wonderful technology invented a few years ago to deal with spam.
It's called Hashcash. All these hacky heuristics like block size are just
dancing around the problem, and the natural solution is already present in
bitcoin: smaller blocks, (down to the point of individual
On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . rayst...@hotmail.com wrote:
No, with no blocksize limit, a spammer would would flood the network with
transactions until they ran out of money.
I think you are forgetting even if you remove the blocksize limit, there is
still a hard message size
On Mon, Jun 08, 2015 at 02:25:40PM -0700, Danny Thorpe wrote:
FWIW, The Open Assets colored coin protocol (CoinPrism) places special
significance on the zeroth input and the position of the OP_RETURN colored
coin marker output to distinguish colored coin issuance outputs from
transfer outputs.
Bitcoin is a global consensus system - if you're (sic) bandwidth isn't
sufficient to keep up you are not part of the consensus.
Bandwidth can be purchased. Infrastructure to handled increasing
transaction volume can be purchased. The very fees being paid by a spammer
will be used to
Not forgetting, simply deferring discussion on that. We’ve a much smaller
limit to deal with right now. But even that limit would have to go to remove
this attack.
From: Btc Drak
Sent: Monday, June 08, 2015 3:07 PM
To: Raystonn .
Cc: Peter Todd ; Bitcoin Dev ; Patrick Mccorry (PGR)
As for IsStandard() rules - let alone soft forks - better to leave
discussion of them out for now.
Removed that bit as well.
Latest version:
https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki
-Kristov
the only way a transaction can be removed from a Bitcoin Core mempool is
through it getting mined, double-spent, or the node restarting.
Right. And that results in some transactions with insufficient fees getting
dropped today after many hours.
The protection that we have against that
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote:
There will always be a blocksize limit based on technological
considerations - the network has a finite bandwidth limit.
A bandwidth limit is not the same as a blocksize limit. Bandwidth
is unique to every individual. Miners in
On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote:
There was this wonderful technology invented a few years ago to deal with
spam. It's called Hashcash. All these hacky heuristics like block size are
just dancing around the problem, and the natural solution is already present
in
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote:
the attack would be expensive.
For attacks being waged to destroy Bitcoin by filling all blocks with spam
transactions, the attack succeeds when the attacker is well funded. This
gives well-funded private and/or public entities
There will always be a blocksize limit based on technological
considerations - the network has a finite bandwidth limit.
A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique
to every individual. Miners in China have different bandwidth and
connectivity than miners in
On Mon, Jun 08, 2015 at 10:13:10PM +, Patrick Mccorry (PGR) wrote:
With the 0.01mBTC/KB minimum
relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and
$23k/GB (assuming $23 * 1000, as each $23 is
13 matches
Mail list logo
