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 min
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
some
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,
> non-p
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 6/30/2015 12:54 PM, Adam Back wrote:
> Secondly on the interests and incentives - miners also play an
> important part of the ecosystem and have gone through some lean times,
> they may not be overjoyed to hear a plan to just whack the block-size
> up to 8MB. While it's true (within some limits
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 data-ce
Moving the list to BCC, since this isn't really a technical discussion.
On Sun, Jun 28, 2015 at 9:37 AM, Venzen Khaosan
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
> should conceptually separ
>"Decentralization" is a popular buzzword these days, but how about
stating the problem description in a way that is more precise and
accurate? One of Bitcoin's differentiating properties is that it
prevents double spending without using a trusted third party.
I have been researching how it ca
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 t
One thing that seems to have been forgotten is that the 1MB block size does
not represent any particular rigorous design choice; it is purely arbitrary.
It does not represent any type of technical sweet-spot; it neither falls
under any reasonable MTU to prevent TCP fragmentation, nor does it
guara
Not that I'm arguing against scaling within tech limits - I agree we
can and should - but note block-size is not a free variable. The
system is a balance of factors, interests and incentives.
As Greg said here
https://www.reddit.com/r/Bitcoin/comments/3b0593/to_fork_or_not_to_fork/cshphic?context
On 06/30/2015 12:05 PM, Peter Todd wrote:
> Well, as you know I have good reason to believe those contracts are
> being actively worked on right now.
Isn't the whole reason they are working on those contracts because a few
miners don't use first-seen in all circumstances as it is? Or as a
corollary
Monetas has developed a Bitmessage address derivation method from an
HD seed based on BIP-43.
https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
We're proposing this as a BIP per the BIP-43 recommendation in order
to reserve a purpose code.
__
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. Ho
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 testn
-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 wrote
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.
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 that
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
t
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 se
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
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
if a miner has to broadcast extra data with his blocks because he's
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 mar
23 matches
Mail list logo
