(Sorry for spam, forgot to cc the mailing list)
RE: miner economics
Miners who have an agenda can forego fees to achieve it and create their
own txns if it is completely txn/user driven. It is better to just count
miners votes and let the user votes be their backing.
Although miners need to
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
Why should miners only be able to vote for double
For the purposes of finding the median, halve same double. It will only
change if a majority of non-apathetic votes are for halve or a majority of
non-apathetic votes are for double.
On Fri, Jun 12, 2015 at 11:54 AM, Matt Whitlock b...@mattwhitlock.name
wrote:
On Friday, 12 June 2015, at 7:44
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm way late to this one, I guess, but adding some thoughts here... it
seems that anything which mitigates the problem of reuse should be to
the maximum extent possible, the user's option... if a person wants to
have an address that lasts forever they
On Fri, Jun 12, 2015 at 1:04 PM, Eric Lombrozo elombr...@gmail.com wrote:
Miners currently only collect an almost negligible portion of their
revenue from fees.
Then they shouldn't care about the block size limit, since an increase in
block size (and thus in the number of txs they get fees
Thanks Bryan for collating these links in one great list. This is very
helpful and thanks for sharing it.
Feel free to fork https://github.com/EthanHeilman/BlockSizeDebate
edit to add the list of proposals and create a pull request to Ethan.
There's also a miningconsensus.slack.com group to have
Hello all,
I've created a simulator for Bitcoin mining which goes a bit further than
the one Gavin used for his blog post a while ago. The main difference is
support for links with different latency and bandwidth, because of the
clustered configuration described below. In addition, it supports
Nice work, Pieter. You're right that my simulation assumed bandwidth for
'block' messages isn't the bottleneck.
But doesn't Matt's fast relay network (and the work I believe we're both
planning on doing in the near future to further optimize block propagation)
make both of our simulations
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote:
The configuration used in the code right now simulates two groups of miners
(one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
internally, but are only connected to each other through a slow 2 Mbit/s
link.
Here
are only connected to each other through a slow 2 Mbit/s link.
That's very slow indeed. For comparison, plain old 3G connections routinely
cruise around 7-8 Mbit/sec.
So this simulation is assuming a speed dramatically worse than a mobile
phone can get!
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
Why should miners only be able to vote for double the limit or halve the
limit? If you're going to use bits, I think you need to use two bits:
0 0 = no preference (wildcard vote)
0 1 = vote for the limit to remain
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their
This is a misguided idea, to say the least. If such a mechanism of of
user input would be possible, one would use it for transaction
verification in the first place. In proof-of-stake outcomes are
determined by vote by stake (that vote has very different
characteristics than vote by compute
If there is a benefit in producing larger more-fee blocks if they propagate
slowly, then there is also a benefit in including high-fee transactions
that are unlikely to propagate quickly through optimized relay protocols
(for example: very recent transactions, or out-of-band receoved ones). This
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks, or conforming incentives among voters by opting
to be with the (slight) majority in order to minimize fees.
Wouldn't it
I'm merely proving the existence of the effect.
On Jun 12, 2015 8:24 PM, Mike Hearn m...@plan99.net wrote:
are only connected to each other through a slow 2 Mbit/s link.
That's very slow indeed. For comparison, plain old 3G connections
routinely cruise around 7-8 Mbit/sec.
So this
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks
Miners could fill their blocks with garbage transactions
Sure, and you did indeed say that.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
Nice work, Pieter. You're right that my simulation assumed bandwidth for
'block' messages isn't the bottleneck.
But doesn't Matt's fast relay network (and the work I believe we're both
planning on doing in the near future to
19 matches
Mail list logo
