Alex Morcos [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-15 📝 Original message:Aaron, My understanding is ...
📅 Original date posted:2015-06-15
📝 Original message: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 at 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 at 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 at 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 at gmail.com> wrote:
>>
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.jpe>;
📝 Original message: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 at 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 at 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 at 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 at gmail.com> wrote:
>>
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.jpe>;