A simple hack to achieve this would be phase shifting the transaction fees
by one block. There may be other problems, but also potential
benefits, with that though.
This hack works because then a miner would orphan a block which didn't
properly reward them, which makes it very costly for even a
It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.
I think it would be better to deploy full-RBF in an opt-in way and
leave the current default miner relay policies as is. So for
example a new signature flag or transaction type that is
On Tue, Jun 30, 2015 at 03:12:52PM +0200, Adam Back wrote:
Any thoughts on the simplest way to support an opt-in version of full-RBF?
Bundle it in with BIP62 version-2 (or whatever) transactions.
- As you desire for RBF, the BIP62 transactions are already specified to
be opt-in. Nobody has to
As you know I'm trying to lobby for a block size increase to a static 8MB.
I'm happy to try to get the testing done that people want done for this,
but I think the real crux of this issue is that we need to get consensus
that we intend to continually push the block size upward as bounded only by
On Tue, Jun 30, 2015 at 03:12:52PM +0200, Adam Back wrote:
It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.
I think it would be better to deploy full-RBF in an opt-in way and
leave the current default miner relay policies as is. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael, I snipped some of your comparison example to comment. I agree
with your sentiment to lobby for testing the change and your offer to
provide resources, yet it presents some (surmountable) challenges:
On 06/30/2015 10:34 PM, Michael Naber
On Tue, Jun 30, 2015 at 09:49:51AM -0400, Chris Pacia wrote:
On 06/30/2015 09:12 AM, Adam Back wrote:
It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.
What would be the effect of IBLT on the first seen policy? It seems that
I’m not planning to take a firm stance against or for, but one problem with
your analogy is that airplanes [currently] are not elastic (until we get TARDIS
technology, or semi-TARDIS-like technology); they take up space and resources
proportional to their capacity.
It is not the block size
Re: Why bother doubling capacity? So that we could have 2x more network
participants of course.
Re: No clear way to scaling beyond that: Computers are getting more capable
aren't they? We'll increase capacity along with hardware.
It's a good thing to scale the network if technology permits it.
On Tue, Jun 30, 2015 at 11:15:31PM +0700, Venzen Khaosan wrote:
Do what's best for Bitcoin and define what needs to get done to
agree to a simple block size increase to a static 8MB.
And this then leads back to the core issue: if an 8MB blocksize
excludes many on this list from testnet,
Moving the list to BCC, since this isn't really a technical discussion.
On Sun, Jun 28, 2015 at 9:37 AM, Venzen Khaosan ven...@mail.bihthai.net
wrote:
Bitcoin's exchange rate, as a commodity money floating freely in the
market, will go up and down according to speculative cycles and we
On 06/30/2015 02:54 PM, Adam Back wrote:
Decentralisation is key to Bitcoin's security model, and it's
differentiating properties.
Continually repeating this statement without defining terms or providing
evidence does not make it true or informative.
Decentralization is a popular buzzword
My understanding is that BIP 101 has working code to raise the block
size and is ready for evaluation today.
When will Lightning and Sidechains be ready so that a fair and
controlled test can be made?
On 06/30/2015 12:54 PM, Adam Back wrote:
People who would like to try the higher tier
The block size debate centers around one concern it seems. To wit: if block
size is increased malicious miners may publish unreasonably large bloated
blocks. The way a miner would do this is to generate a plethora of private,
non-propagated transactions and include these in the block they solve.
On Tuesday, June 30, 2015 11:41:29 PM Peter Grigor wrote:
The block size debate centers around one concern it seems. To wit: if block
size is increased malicious miners may publish unreasonably large bloated
blocks. The way a miner would do this is to generate a plethora of private,
The problem with this approach is that you need 100% exact behaviour for
every node on the network in their decision to reject a particular block.
So we need a 100% mempool synchronization across all nodes - otherwise just
an attempted double spend could result in a fork in the network because
16 matches
Mail list logo
