Jimmy Song [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-11 📝 Original message:Jorge, I'll be happy to ...
📅 Original date posted:2017-04-11
📝 Original message:Jorge, I'll be happy to discuss with you more about whether allowing
ASICBoost would actually secure the network more or not, but that's not my
main motivation. My main motivation is to get more miners to accept segwit.
The version bit usage part, I don't believe requires any code changes as
those bits aren't being used by BIP9 anyway, though some cleanup to
restrict them later is probably a good idea.
The requiring witness commitment part would require some changes, but
according to Timo Hanke, that's actually not necessary as overt is so much
more efficient.
In any case, I'm happy to close this discussion until there's some
indication that more miners would accept segwit as a result of this change.
Jimmy
On Tue, Apr 11, 2017 at 4:25 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I've changed the proposal so only 8 bits are given to grinding so
> something
> > like 20 bits are available for signaling.
> >
> > I have to say I'm at a loss here as to what's next? Should I make a new
> BIP
> > or try to convince the authors of BIP141 to modify their BIP? Could
> someone
> > inform me on the next part of the process?
>
> See bip2, specifically
> https://github.com/bitcoin/bips/blob/master/bip-0002.
> mediawiki#bip-workflow
>
> "Following a discussion, the proposal should be submitted to the BIPs
> git repository as a pull request. This draft must be written in BIP
> style as described below, and named with an alias such as
> "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
> number (authors MUST NOT self-assign BIP numbers)."
>
> But I think it's kind of late to modify bip141, given that there's
> code out there with the current specification.
> I guess you can propose extensions or alternatives to replace it. I'm
> really not sure what's the next step, but I don't think you have
> provided enough motivation as to why we would want to maintain
> asicboost. You said it makes the network more secure, but that's not
> the case, as explained, not even if all honest miners use it.
>
> > On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Tom Zander wrote:
> >>
> >> > The version field is still needed to actually allow future block
> version
> >> > upgrades. We would cut off our road forward if that were to be
> blocked.
> >>
> >> I tend to agree, if all 32 bits were given up to grinding.
> >>
> >> But it's worth pointing out that BIP9 is purely informational, and the
> top
> >> 3 bits are still reserved for other purposes. One of them could perhaps
> be
> >> used to signal for an extended version field somewhere else, leaving the
> >> bottom 29 as entropy?
> >>
> >> Not a direction I prefer, but just a technical possibility perhaps.
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170411/95a10ad4/attachment.html>;
📝 Original message:Jorge, I'll be happy to discuss with you more about whether allowing
ASICBoost would actually secure the network more or not, but that's not my
main motivation. My main motivation is to get more miners to accept segwit.
The version bit usage part, I don't believe requires any code changes as
those bits aren't being used by BIP9 anyway, though some cleanup to
restrict them later is probably a good idea.
The requiring witness commitment part would require some changes, but
according to Timo Hanke, that's actually not necessary as overt is so much
more efficient.
In any case, I'm happy to close this discussion until there's some
indication that more miners would accept segwit as a result of this change.
Jimmy
On Tue, Apr 11, 2017 at 4:25 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I've changed the proposal so only 8 bits are given to grinding so
> something
> > like 20 bits are available for signaling.
> >
> > I have to say I'm at a loss here as to what's next? Should I make a new
> BIP
> > or try to convince the authors of BIP141 to modify their BIP? Could
> someone
> > inform me on the next part of the process?
>
> See bip2, specifically
> https://github.com/bitcoin/bips/blob/master/bip-0002.
> mediawiki#bip-workflow
>
> "Following a discussion, the proposal should be submitted to the BIPs
> git repository as a pull request. This draft must be written in BIP
> style as described below, and named with an alias such as
> "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
> number (authors MUST NOT self-assign BIP numbers)."
>
> But I think it's kind of late to modify bip141, given that there's
> code out there with the current specification.
> I guess you can propose extensions or alternatives to replace it. I'm
> really not sure what's the next step, but I don't think you have
> provided enough motivation as to why we would want to maintain
> asicboost. You said it makes the network more secure, but that's not
> the case, as explained, not even if all honest miners use it.
>
> > On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Tom Zander wrote:
> >>
> >> > The version field is still needed to actually allow future block
> version
> >> > upgrades. We would cut off our road forward if that were to be
> blocked.
> >>
> >> I tend to agree, if all 32 bits were given up to grinding.
> >>
> >> But it's worth pointing out that BIP9 is purely informational, and the
> top
> >> 3 bits are still reserved for other purposes. One of them could perhaps
> be
> >> used to signal for an extended version field somewhere else, leaving the
> >> bottom 29 as entropy?
> >>
> >> Not a direction I prefer, but just a technical possibility perhaps.
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170411/95a10ad4/attachment.html>;