From: Luke Dashjr <luke@dashjr•org>
To: Cory Fields <lists@coryfields•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SegWit GBT updates
Date: Mon, 1 Feb 2016 23:08:34 +0000 [thread overview]
Message-ID: <201602012308.35215.luke@dashjr.org> (raw)
In-Reply-To: <CAApLimgF2D97rAL8A9G36ULBE5tqKoXHFawYi35a0JiuQRu4Zg@mail.gmail.com>
On Monday, February 01, 2016 9:43:33 PM Cory Fields wrote:
> On Mon, Feb 1, 2016 at 2:46 PM, Luke Dashjr <luke@dashjr•org> wrote:
> > Allowing for simpler cases both encourages the lazy case, and enables
> > pools to require miners use it. It also complicates the server-side
> > implementation somewhat, and could in some cases make it more vulnerable
> > to DoS attacks. Keep in mind that GBT is not merely a bitcoind protocol,
> > but is used between pool<->miner as well... For now, it makes sense to
> > leave
> > "default_witness_commitment" as a bitcoind-specific extension to
> > encourage adoption, but it seems better to leave it out of the standard
> > protocol. Let me know if this makes sense or if I'm overlooking
> > something.
>
> I think that's a bit of a loaded answer. What's to keep a pool from
> building its own commitment and requiring miners to use that? I don't
> see how providing the known-working commitment for the
> passed-in-hashes allows the pool/miner to do anything they couldn't
> already, with the exception of skipping some complexity. Please don't
> confuse encouraging with enabling.
Making it simpler to do a centralised implementation than a decentralised one,
is both enabling and encouraging. GBT has always been designed to make it
difficult to do in a centralised manner.
> What's the DoS vector here?
It's more work for the pool to provide it, similar to the "midstate" field was
with getwork. Someone performing a DoS needs to do less work to force the pool
to do complex calculations (unless the same transaction tree / commitment is
used for all miners, which would be an unfortunate limitation).
> >> The issue in particular here is that a non-trivial burden is thrust
> >> upon mining software, increasing the odds of bugs in the process.
> >
> > It can always use libblkmaker to handle the "heavy lifting"... In any
> > case, the calculation for the commitment isn't significantly more than
> > what it must already do for the stripped merkle tree.
>
> Agreed. However for the sake of initial adoption, it's much easier to
> have a known-correct value to use. Even if it's just for the sake of
> checking against.
Sure, I'm not suggesting we remove this from bitcoind (probably the only place
that makes initial adoption easier).
> >> [4]:
> >> https://github.com/theuni/ckpool/commit/7d84b1d76b39591cc1c1ef495ebec513
> >> cb 19a08e
> >
> > I'm pretty sure this commit is actually /introducing/ a bug in working
> > (albeit ugly) code. The height, while always positive, is serialised as
> > a signed number, so 0x80 needs to be two bytes: 80 00.
>
> You're right, thanks. The current code breaks on heights of (for ex)
> 16513. I'll fix up my changes to take the sign bit into account.
I'm curious what bug it was fixing? Was it overwriting data beyond the number?
Luke
next prev parent reply other threads:[~2016-02-01 23:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-30 18:50 Luke Dashjr
2016-02-01 18:41 ` Cory Fields
2016-02-01 19:46 ` Luke Dashjr
2016-02-01 21:43 ` Cory Fields
2016-02-01 23:08 ` Luke Dashjr [this message]
2016-02-02 1:40 ` Cory Fields
2016-02-02 2:30 ` Luke Dashjr
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=201602012308.35215.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lists@coryfields$(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