From: Aaron Voisine <voisine@gmail•com>
To: Alex Morcos <morcos@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
Date: Mon, 15 Jun 2015 21:00:19 -0700 [thread overview]
Message-ID: <CACq0ZD6M5Rv_iaB8=7_XgG-QX21CvxCf_Wm5ciRALgRYPt=eYw@mail.gmail.com> (raw)
In-Reply-To: <CAPWm=eWTnVCoRCGSycUGsYjx8M3NFdqEXAU1ykm08_FdJQCP5Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 9655 bytes --]
Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
should at least prevent nodes from crashing. When I looked a few days ago I
only found a few old PRs that seemed to have fallen by the wayside, so this
new one is encouraging.
I can respond in the PR comments if it's more appropriate there, but I
believe ejecting tx from mempools rather than preemptively refusing them
according to standard network wide propagation rules will result in spotty,
inconsistent tx propagation, and possibly a large increase in tx
re-broadcasts, so if those haven't been addressed they will need to be. It
would also be prudent to run some simulations to see what other issues are
going to pop-up.
We're currently using CPFP already in breadwallet when spending unconfirmed
non-change inputs. A small percentage of hashing power is using it, but
enough to get a transaction unstuck assuming breadwallet's fee calculation
is better than the sender's.
The problem with RBF is that there's currently no way to tell if your tx
has been picked up by miners or not in order to know if you need to replace
it. Miners broadcasting partial block solutions would be helpful in this
regard, but only for tx in the currently-being-worked-on block, not for tx
that won't be picked up until the block after. If miners were to eject tx
that were previously being worked on in favor of higher fee tx, then that
causes another set of problems for wallets that thought their tx was going
to get in but then it doesn't. The other problem with RBF is that users
don't know up front what fee they're actually going to pay which is a big
blow to real world usability. Also mobile wallets will have to sign lots of
tx up front and rely on a service to replace as necessary. And this is all
just on the send side. On the receive side it's much worse since you can't
rely on the sender to do the replacing. The real problem seems to be the
fact that RBF is an interactive iterative process rather than a
send-and-forget one.
What you really need is some way to tell up-front, is a transaction going
to get mined with a high probability? That problem seems really difficult
to solve with fixed-size blocks that are full. If the goal is simply to
reduce or limit the growth of the blockchain, then there are much simpler
solutions, which is why I've advocated for the blocksize increase, followed
by tx selection and propagation rule changes to create fee pressure.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Mon, Jun 15, 2015 at 6:17 PM, Alex Morcos <morcos@gmail•com> wrote:
> Aaron,
>
> My understanding is that Gavin and Mike are proceeding with the XT fork, I
> hope that understanding is wrong.
>
> As for improving the non-consensus code to handle full blocks more
> gracefully. This is something I'm very interested in, block size increase
> or not. Perhaps I shouldn't hijack this thread, but maybe there are others
> who also believe this would ameliorate some of the time pressure for
> deciding on a block size increase.
>
> What is it that you would like to see improved?
> The fee estimation code that is included for 0.11 will give much more
> accurate fee estimates, which should allow adding the correct fee to a
> transaction to see it likely to be confirmed in a reasonable time. For
> further improvements:
> - There has recently been attention to overhauling the block creation and
> mempool limiting code in such a way that actual outstanding queues to be
> included in a block could also be incorporated in fee estimation. See
> https://github.com/bitcoin/bitcoin/pull/6281.
> - CPFP and RBF are candidates for inclusion in core soon, both of which
> could be integrated into transaction processing to handle the edge cases
> where a priori fee estimation fails. See
> https://github.com/bitcoin/bitcoin/pull/1647 and
> https://github.com/bitcoin/bitcoin/pull/6176
>
> I know there has been much discussion of fee estimation not working for
> SPV clients, but I believe several independent servers which were serving
> the estimates from full nodes would go a long way towards allowing that
> information to be used by SPV clients even if its not a completely
> decentralized solution. See for example
> http://core2.bitcoincore.org/smartfee/latest.json
>
>
>
> On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine@gmail•com> wrote:
>
>> Wasn't the XT hard fork proposed as a last resort, should the
>> bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants
>> to go that route. An alternate hard-fork proposal like BIP100 that gets
>> consensus, or a modified version of gavin's that ups the limit to 8Mb
>> instead of 20Mb, or hell even some major changes to the non-consunsus code
>> to make it adequately handle the situation when blocks fill up, and allow
>> wallet software to continue working with a send-and-forget use pattern, any
>> of these would be enough to avoid the need for an XT only hard-fork.
>>
>> So far BIP100 is the only one that seems to actually be getting any sort
>> of momentum toward consensus, and it was proposed... 2 days ago? When the
>> XT fork was proposed as a last resort, it was when the opponents were (to
>> my understanding) suggesting we just let blocks fill up, and hopefully
>> things would just work out on their own.
>>
>>
>>
>> Aaron Voisine
>> co-founder and CEO
>> breadwallet.com
>>
>> On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman@gmail•com>
>> wrote:
>>
>>> Who is actually planning to move to Bitcoin-XT if this happens?
>>>
>>> Just Gavin and Mike?
>>>
>>> [image: image1.JPG]
>>>
>>> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail•com> wrote:
>>>
>>> I'm quite puzzled by the response myself, it doesn't seem to address
>>> some of the (more serious) concerns that Adam put out, the most important
>>> question that was asked being the one regarding personal ownership of the
>>> proposed fork:
>>>
>>> "How do you plan to deal with security & incident response for the
>>> duration you describe where you will have control while you are deploying
>>> the unilateral hard-fork and being in sole maintainership control?"
>>>
>>> I do genuinely hope that whomever (now and future) wishes to fork the
>>> protocol reconsider first whether they are truly ready to test/flex their
>>> reputation/skills/resources in this way... Intuitively, to me it seems
>>> counterproductive, and I don't fully believe it is within a single
>>> developer's talents to manage the process start-to-finish (as it is
>>> non-trivial to hard-fork successfully, others have rehashed this in other
>>> threads)...
>>>
>>> That being said I think it appropriate if Adam's questions were
>>> responded in-line when Mike is feeling up to it. I think that the answers
>>> are important for the community to hear when such a drastic change is being
>>> espoused.
>>>
>>> Faiz
>>>
>>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure@gmail•com> wrote:
>>>
>>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99•net> wrote:
>>>>
>>>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
>>>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the
>>>>> error of their ways. Anyone can write blogs.
>>>>>
>>>>
>>>> I worry that if this is the level of care you take with reading and
>>>> (mis)interpreting Adam's messages, that you might not be taking extreme
>>>> care with evaluating consensus changes, even while tired or sleeping. I
>>>> encourage you to evaluate both messages and source code more carefully,
>>>> especially in the world of bitcoin. However, this goes for everyone and not
>>>> just you. Specifically, when Adam mentioned your conversations with
>>>> non-technical people, he did not mean "Mike has talked with people who have
>>>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a
>>>> non-programmer". Communication is difficult and I can understand that, but
>>>> we really have to be more careful when evaluating each other's messages;
>>>> technical miscommunication can be catastrophic in this context. On the
>>>> topic of whether you are a programmer, I suspect that ever since you built
>>>> CIA.vc we have all known you're a programmer, Mike.
>>>>
>>>> - Bryan
>>>> http://heybryan.org/
>>>> 1 512 203 0507
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development@lists•sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>> --
>>>>
>>>> My regards,
>>>>
>>>> Faiz Khan
>>>>
>>>> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
[-- Attachment #1.2: Type: text/html, Size: 13757 bytes --]
[-- Attachment #2: image1.JPG --]
[-- Type: image/jpeg, Size: 22107 bytes --]
next prev parent reply other threads:[~2015-06-16 4:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 0:04 Adam Back
2015-06-15 9:56 ` Mike Hearn
2015-06-15 18:03 ` Adam Back
2015-06-15 20:55 ` Mike Hearn
2015-06-15 21:56 ` Bryan Bishop
2015-06-15 22:17 ` Faiz Khan
2015-06-15 22:56 ` Brian Hoffman
2015-06-15 23:05 ` [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Raystonn .
2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine
2015-06-16 0:41 ` Mark Friedenbach
2015-06-16 1:17 ` Alex Morcos
2015-06-16 4:00 ` Aaron Voisine [this message]
2015-06-17 3:54 ` Peter Todd
2015-06-18 15:23 ` Jorge Timón
2015-06-16 11:29 ` Mike Hearn
2015-06-16 11:20 ` Mike Hearn
2015-06-16 12:33 ` Pindar Wong
2015-06-16 13:33 ` Peter Todd
2015-06-16 13:55 ` Pindar Wong
2015-06-17 3:59 ` Peter Todd
2015-06-25 6:43 ` [bitcoin-dev] " Pindar Wong
2015-06-26 19:30 ` Peter Todd
2015-06-15 22:54 ` odinn
2015-06-16 1:20 ` Eric Lombrozo
2015-06-16 5:18 ` Venzen
2015-06-16 6:09 ` Marcel Jamin
2015-06-16 9:21 ` Benjamin
2015-06-16 11:01 ` Tier Nolan
2015-06-17 3:52 ` Troy Benjegerdes
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='CACq0ZD6M5Rv_iaB8=7_XgG-QX21CvxCf_Wm5ciRALgRYPt=eYw@mail.gmail.com' \
--to=voisine@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=morcos@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