From: Sergio Lerner <sergiolerner@certimix•com>
To: Leo Wandersleb <leo@LeoWandersleb•de>,
"bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
Date: Tue, 12 May 2015 15:55:05 -0300 [thread overview]
Message-ID: <55524C89.6080705@certimix.com> (raw)
In-Reply-To: <5551021E.8010706@LeoWandersleb.de>
[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]
On 11/05/2015 04:25 p.m., Leo Wandersleb wrote:
> I assume that 1 minute block target will not get any substantial support but
> just in case only few people speaking up might be taken as careful
support of
> the idea, here's my two cents:
>
> In mining, stale shares depend on delay between pool/network and the
miner. This
> varies substantially globally and as Peter Todd/Luke-Jr mentioned,
speed of
> light will always keep those at a disadvantage that are 100 light
milli seconds
> away from the creation of the last block. If anything, this warrants
to increase
> block target, not reduce. (The increase might wait until we have
miners on Mars
> though ;) )
An additional delay of 200 milliseconds means loosing approximately 0.3%
of the revenue.
Do you really think this is going to be the key factor to prevent a
mining pool from being used?
There are lot of other factors, such as DoS protections, security,
privacy, variance, trust, algorithm to distribute shares, that are much
more important than that.
And having a 1 minute block actually reduces the payout variance 10x, so
miners will be happy for that. And many pool miners may opt to do solo
mining, and create new full-nodes.
>
>
> If SPV also becomes 10 times more traffic intensive, I can only urge
you to
> travel to anything but central Europe or the USA.
The SPV traffic is minuscule. Bloom-filers are an ugly solution that
increases bandwidth and does not provide a real privacy solution.
Small improvements in the wire protocol can reduce the traffic two-fold.
>
>
> I want bitcoin to be the currency for the other x billion and thus I
oppose any
> change that moves the balance towards the economically upper billion.
Because having a 10 minute rate Bitcoin is a good Internet money. If you
have a 1 minute rate, then it can also be a retail payment method, an
virtual game trading payment method, a gambling, XXX-video renting
(hey, it takes less than 10 minutes to see one of those :), and much more.
You can reach more billions by having near instant payments.
Don't tell me about the morning caffe, I would like that everyone is
buying their coffe with Bitcoin and there are millions of users before
we figure out how to do that off-chain.
Best regards,
Sergio.
[-- Attachment #2: Type: text/html, Size: 3062 bytes --]
next prev parent reply other threads:[~2015-05-12 18:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 7:03 Sergio Lerner
2015-05-11 10:34 ` Peter Todd
2015-05-11 11:10 ` insecurity
2015-05-11 11:49 ` Dave Hudson
2015-05-11 12:34 ` Christian Decker
2015-05-11 16:47 ` Luke Dashjr
[not found] ` <5551021E.8010706@LeoWandersleb.de>
2015-05-12 18:55 ` Sergio Lerner [this message]
2015-05-11 7:30 Thy Shizzle
2015-05-11 8:16 ` Dave Hudson
2015-05-11 8:50 insecurity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55524C89.6080705@certimix.com \
--to=sergiolerner@certimix$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=leo@LeoWandersleb$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox