It won't work as you thought. If a miner has 95% of hashing power, he
would have 95% of chance to find the next block and collect the penalty.
In long term, he only needs to pay 5% penalty. It's clearly biased
against small miners.
Instead, you should require the miners to burn the penalty. Wh
On 7 August 2015 at 09:52, Wes Green via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Bitcoin is built on game theory. Somehow we seem to have forgotten that
> and are trying to fix our "block size issue" with magic numbers, projected
> percentage growth of bandwidth speeds, time
I think the key is comity and humility in terms of being honest about our
inability to predict future trends in a meaningful way while passing through
scrutiny coming from divergent perspectives. 8MB + 40% annually (at whatever
increase frequency is preferred, at coinbase halvings seems most id
Bitcoin is built on game theory. Somehow we seem to have forgotten that and
are trying to fix our "block size issue" with magic numbers, projected
percentage growth of bandwidth speeds, time limits, etc... There are
instances where these types of solutions make sense, but this doesn't
appear to be
On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
"Miners can do this unilaterally" maybe, if they are a closed group, based
> on the 51% rule. But aren't they using full nodes for propagation? In this
> sense, anyone can vote by coding.
"Miners can do this unilaterally" maybe, if they are a closed group, based
on the 51% rule. But aren't they using full nodes for propagation? In this
sense, anyone can vote by coding.
If and when we need to vote, a pair-wise runoff ("condorcet method") will
find an option that is championed by a
On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón wrote:
>
>
> Given that for any non-absurdly-big size some transactions will
> eventually be priced out, and that the consensus rule serves for
> limiting mining centralization (and more indirectly centralization in
> general) and not about trying to set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2015 10:21:54 GMT-04:00, Gavin Andresen via bitcoin-dev
wrote:
>On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille
>
>wrote:
>
>> But you seem to consider that a bad thing. Maybe saying that you're
>> claiming that this equals Bitcoin fai
Really, thanks again for replying and not getting mad when I get your
thoughts wrong.
I believe that I've learned more about your position on the subject
today than in months of discussion and blogs (that's not a critique to
your blog post, it's just that they didn't answer to some questions
that I
On August 6, 2015 8:17:35 PM GMT+02:00, Tom Harding via bitcoin-dev
wrote:
>On 8/6/2015 10:16 AM, Sergio Demian Lerner via bitcoin-dev wrote:
>> Is there any up to date documentation about TheBlueMatt relay network
>> including what kind of block compression it is currently doing?
>(apart
>> fr
On August 6, 2015 8:42:38 PM GMT+02:00, Gregory Maxwell via bitcoin-dev
wrote:
>On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
> wrote:
>> - Will the relay network at least validate block version numbers in
>the
>> future?
>
>It already validates block version numbers.
>
>It only
No, don't think so, the protocol is, essentially, relay transactions, when you
get a block, send header, iterate over transactions, for each, either use two
bytes for nth-recent-transaction-relayed, use
0x-3-byte-length-transaction-data. There are quite a few implementation
details, and lot
On Aug 6, 2015 9:42 PM, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
2. The "market minimum fee" should be determined by the market. It should
not be up to us to decide "when is a good time."
I partially agree. The community should decide what risks it is willin
On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón wrote:
> So I reformulate the question:
>
> 1) If "not now", when will it be a good time to let the "market
> minimum fee for miners to mine a transaction" rise above zero?
Two answers:
1. If you are willing to wait an infinite amount of time, I thin
On Thu, Aug 6, 2015 at 8:43 PM, Michael Naber wrote:
> How many nodes are necessary to ensure sufficient network reliability?
> Ten, a hundred, a thousand? At what point do we hit the point of
> diminishing returns, where adding extra nodes starts to have negligible
> impact on the overall reliab
How many nodes are necessary to ensure sufficient network reliability? Ten,
a hundred, a thousand? At what point do we hit the point of diminishing
returns, where adding extra nodes starts to have negligible impact on the
overall reliability of the system?
On Thu, Aug 6, 2015 at 10:26 AM, Piet
On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
wrote:
> - Will the relay network at least validate block version numbers in the
> future?
It already validates block version numbers.
It only relays valid transactions.
Although, the block relaying itself is explicitly "unvalidated"
On 8/6/2015 10:16 AM, Sergio Demian Lerner via bitcoin-dev wrote:
> Is there any up to date documentation about TheBlueMatt relay network
> including what kind of block compression it is currently doing? (apart
> from the source code)
>
Another question.
Did the "relay network" relay
Other than the source code, the best documentation I've come across is a few
lines on IRC explaining the high-level design of the protocol:
https://botbot.me/freenode/bitcoin-wizards/2015-07-10/?msg=44146764&page=2
On Thu, Aug 6, 2015 at 10:18 AM Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@
Is there any up to date documentation about TheBlueMatt relay network
including what kind of block compression it is currently doing? (apart from
the source code)
Regards, Sergio.
On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On
First of all, thank you very much for answering the questions, and
apologies for not having formulated them properly (fortunately that's
not an irreparable mistake).
On Thu, Aug 6, 2015 at 6:03 PM, Gavin Andresen wrote:
> On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón wrote:
>>
>> 1) If "not now"
I am a long time Bitcoin user, miner, investor, full node operator, and
distributed real-time system software engineer.
Out of the all currently proposed blocksize increase solutions, I support
BIP101 (or something like it) and find the current blocksize debate very
frustrating, so I will try to s
On 8/6/2015 7:53 AM, Pieter Wuille via bitcoin-dev wrote:
>
> So if we would have 8 MB blocks, and there is a sudden influx of users
> (or settlement systems, who serve much more users) who want to pay
> high fees (let's say 20 transactions per second) making the block
> chain inaccessible for low
Whilst 1mb to 8mb might seem irrelevant from a pure computer science
perspective payment demand is not really infinite, at least not if by
"payment" we mean something resembling how current Bitcoin users use the
network.
If we define "payment" to mean the kind of thing that Bitcoin users and
enthu
On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón wrote:
> 1) If "not now" when will it be a good time to let fees rise above zero?
>
Fees are already above zero. See
http://gavinandresen.ninja/the-myth-of-not-full-blocks
> 2) When will you consider a size to be too dangerous for centralization?
>
On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen
wrote:
> On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille
> wrote:
>
>> So if we would have 8 MB blocks, and there is a sudden influx of users
>> (or settlement systems, who serve much more users) who want to pay high
>> fees (let's say 20 transaction
On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen wrote:
> On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón
> wrote:
>>
>> This is a much more reasonable position. I wish this had been starting
>> point of this discussion instead of "the block size limit must be
>> increased as soon as possible or bitcoi
On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille
wrote:
> So if we would have 8 MB blocks, and there is a sudden influx of users (or
> settlement systems, who serve much more users) who want to pay high fees
> (let's say 20 transactions per second) making the block chain inaccessible
> for low fee
On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen
wrote:
> On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille
> wrote:
>
>> But you seem to consider that a bad thing. Maybe saying that you're
>> claiming that this equals Bitcoin failing is an exaggeration, but you do
>> believe that evolving towards an
On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille
wrote:
> But you seem to consider that a bad thing. Maybe saying that you're
> claiming that this equals Bitcoin failing is an exaggeration, but you do
> believe that evolving towards an ecosystem where there is competition for
> block space is a bad
On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is a much more reasonable position. I wish this had been starting
>> point of thi
On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This is a much more reasonable position. I wish this had been starting
> point of this discussion instead of "the block size limit must be
> increased as soon as possible or bitcoin will fail".
>
It REAL
32 matches
Mail list logo
