>
> 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
--
Hey Peter, thanks for your experienced feedback.
On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd 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 to the use-cases
> 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 incre
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
>
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 $2
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
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)
Subject:
On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . 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 limit imposed by the p
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 transacti
> 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 i
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 enti
> 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 at
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 outpu
> 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 the means to destroy Bitcoin if they
desire. This is only true
On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote:
> > there is no memory pool cap currently
>
> Real hardware does not have an infinite amount of RAM. Memory pool sizes
> cannot grow unbounded. Some transactions with insufficient fees do get
> dropped today after many hours.
Actuall
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. Reordering the inputs or the outputs breaks the colored
coin repre
> If I were a miner under this attack, I would just use the spam to fill up
> blocks alongside normal transactions maximising my profit.
You are assuming here that you can identify which transactions are spam, and
which are not, and then segregate the spam into a separate channels of
transactio
When implemented, the block size limit was put in place to prevent the
potential for a massive block to be used as an attack to benefit the miner
of that block. The theory goes that such a massive block would enrich its
miner by delaying other miners who are now busy downloading and validating
18 matches
Mail list logo
