From: Angel Leon <gubatron@gmail•com>
To: Rodney Morris <rodney.morris@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Date: Mon, 17 Aug 2015 08:38:06 -0400 [thread overview]
Message-ID: <CADZB0_a448SROLVLiYb3-zVPaX0+u1FHwZHSkeLgdS1s2BBsOg@mail.gmail.com> (raw)
In-Reply-To: <CABerxhEwA7Pz0hdSuOf+RwWZiZpY1fSArB+UiyVUwr6S2fr3vQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2914 bytes --]
I've been sharing a similar solution for the past 2 weeks. I think 2016
blocks is too much of a wait, I think we should look at the mean block size
during the last 60-120 minutes instead and avert any crisis caused by
transactional spikes that could well be caused by organic use of the
network (Madonna sells her next tour tickets on Bitcoin, OpenBazaar network
starts working as imagined, XYZ startup really kicks ass and succeeds in a
couple of major cities with major PR push)
Pseudo code in Python
https://gist.github.com/gubatron/143e431ee01158f27db4
My idea stems from a simple scalability metric that affects real users and
the desire to use Bitcoin:
Waiting times to get your transactions confirmed on the blockchain.
Anything past 45mins-1 hour should be unnacceptable.
Initially I wanted to measure the mean time for the transactions in blocks
to go from being sent by the user
(initial broadcast into mempools) until the transaction was effectively
confirmed on the blockchain, say for 2 blocks (acceptable 15~20mins)
When blocks get full, people start waiting unnaceptable times for their
transactions to come through
if they don't adjust their fees. The idea is to avoid that situation at all
costs and keep the network
churning to the extent of its capabilities, without pretending a certain
size will be right at some
point in time, nobody can predict the future, nobody can predict real
organic usage peaks
on an open financial network, not all sustained spikes will come from
spammers,
they will come from real world use as more and more people think of great
uses for Bitcoin.
I presented this idea to measure the mean wait time for transactions and I
was told
there's no way to reliably meassure such a number, there's no consensus
when transactions are still
in the mempool and wait times could be manipulated. Such an idea would have
to include new timestamp fields
on the transactions, or include the median wait time on the blockheader
(too complex, additional storage costs)
This is an iteration on the next thing I believe we can all agree is 100%
accurately measured, blocksize.
Full blocks are the cause why many transactions would have to be waiting in
the mempool, so we should be able
to also use the mean size of the blocks to determine if there's a
legitimate need to increase or reduce the
maximum blocksize.
The idea is simple, If blocks are starting to get full past a certain
threshold then we double the blocksize
limit starting the next block, if blocks remain within a healthy bound,
transaction wait times should be as
expected for everyone on the network, if blocks are not getting that full
and the mean goes below a certain
threshold then we half the maximum block size allowed until we reach the
level we need.
Similar to what we do with hashing difficulty, it's something you can't
predict, therefore no fixed limits,
or predicted limits should be established.
[-- Attachment #2: Type: text/html, Size: 4057 bytes --]
next prev parent reply other threads:[~2015-08-17 12:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 11:57 Rodney Morris
2015-08-17 12:38 ` Angel Leon [this message]
2015-08-17 12:43 ` Tier Nolan
-- strict thread matches above, loose matches on Subject: below --
2015-08-21 21:45 Upal Chakraborty
2015-08-20 15:02 Upal Chakraborty
2015-08-18 12:13 Upal Chakraborty
2015-08-18 17:26 ` Chris Wardell
2015-08-20 7:31 ` Jorge Timón
2015-08-20 10:23 ` Milly Bitcoin
2015-08-21 0:25 ` Tom Harding
2015-08-21 0:37 ` Peter Todd
2015-08-21 16:52 ` Tom Harding
2015-08-21 22:21 ` Peter Todd
2015-08-21 23:16 ` Tom Harding
2015-08-22 0:01 ` Peter Todd
2015-08-22 3:21 ` Jorge Timón
2015-08-22 6:26 ` Peter Todd
2015-08-23 23:41 ` Tom Harding
2015-08-24 2:27 ` Jorge Timón
2015-08-21 0:45 ` Milly Bitcoin
2015-08-21 0:58 ` Peter Todd
2015-08-21 1:30 ` Milly Bitcoin
2015-08-21 20:28 ` Jorge Timón
2015-08-21 12:13 ` Sriram Karra
2015-08-21 20:09 ` Jorge Timón
2015-08-18 19:44 ` cedric perronnet
2015-08-18 20:58 ` Danny Thorpe
2015-08-18 21:17 ` Chris Wardell
2015-08-19 17:21 ` Upal Chakraborty
2015-08-17 9:44 Upal Chakraborty
2015-08-17 9:54 ` Levin Keller
2015-08-17 9:59 ` Patrick Strateman
2015-08-17 10:51 ` Btc Drak
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=CADZB0_a448SROLVLiYb3-zVPaX0+u1FHwZHSkeLgdS1s2BBsOg@mail.gmail.com \
--to=gubatron@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rodney.morris@gmail$(echo .)com \
/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