-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hey Bitcoiners!
While I am an avid Bitcoin supporter, long-term user, and have done
development work on tools and platforms surrounding Bitcoin, I have
been very busy these past few weeks and haven't had a chance to fully
(or closely) monitor the Bl
Ah, then my mistake. It seemed so similar to an idea that was proposed
before on this mailing list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
that my mind just filled in the gaps. I concur -- having miners -- or any
group -- vote on block size is not an intrinsic
On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.
I realize now that this is not what Greg Maxwell proposed (aka
flexcap): this is just miner's voting on block size
On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size will never increase under this proposal do to a collective action
> problem. If a miner votes for an increase and nobody else does, the
> b
On Sat, Aug 29, 2015 at 1:36 AM, Btc Drak via bitcoin-dev
wrote:
> On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock
> wrote:
>> However, this proposal currently fails to answer a very important question:
>>
>> • What is the mechanism for activation of the new consensus rule? It is when
>> a cert
On Aug 28, 2015 7:38 PM, "Mark Friedenbach" wrote:
>
> It is in their individual interests when the larger block that is allowed
for them grants them more fees.
And pay a difficulty penalty and lose full blocks because of it? Even if
fees are somehow high enough to compensate for the lost reward,
But that's not what this proposal does. They have to pay the difficulty penalty
merely for a *chance* at later being able to mine larger blocks.
Maybe this could be fixed by allowing miners to produce a larger-than-limit
block *immediately* by paying a difficulty penalty. Then we can simply take
On Fri, Aug 28, 2015 at 11:24 PM, Gavin wrote:
> With this proposal, how much would it cost a miner to include an 'extra'
> 500-byte transaction if the average block size is 900K and it costs the miner
> 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is
It is in their individual interests when the larger block that is allowed
for them grants them more fees.
On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size
On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock wrote:
> However, this proposal currently fails to answer a very important question:
>
> • What is the mechanism for activation of the new consensus rule? It is when
> a certain percentage of the blocks mined in a 2016-block retargeting period
> co
When discussing this with Matt Whitlock earlier we basically concluded the
block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalt
With this proposal, how much would it cost a miner to include an 'extra'
500-byte transaction if the average block size is 900K and it costs the miner
20BTC in electricity/capital/etc to mine a block?
If my understanding of the proposal is correct, it is:
500/90 * 20 = 0.1 BTC
... Or $
This is the best proposal I've seen yet. Allow me to summarize:
• It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their
block-size votes.
• It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to
predict future market needs versus future technological ca
On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock via bitcoin-dev
wrote:
> Why would you use a hash of hashes? Wouldn't it be simpler and just as
> effective to use either:
>
> 1) the genesis block hash, or
If it's a new chain, we're talking about a "spinoffs"
https://bitcointalk.org/index.php?top
I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.
I also request the BIP maintainer for a BIP number assignment
[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2]
https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_
Why would you use a hash of hashes? Wouldn't it be simpler and just as
effective to use either:
1) the genesis block hash, or
2) the block hash of the first block in a fork?
Every block hash in a chain implicitly subsumes the genesis block hash of that
chain, so there's no need to incorporate t
I have an ugly solution to this problem, with minimal change to the
current softfork logic, and still allows all features described in
sipa's Version bits BIP
1. xVersion = nVersion AND 0b10011000
2. miners supporting BIP65 will set xVersion = 8 or greater
3. If 750 of t
There has been discussion of using the genesis block hash to identify
chains in BIP 21 (bitcoin:// URI scheme). However, this does not allow
identification between blockchain forks building upon the same genesis
block. While many see this as undesirable, I think it is inevitable that
this will even
18 matches
Mail list logo
