public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph.org>
To: Mark Friedenbach <mark@friedenbach.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Wed, 9 Dec 2015 07:17:08 +0000	[thread overview]
Message-ID: <CAAS2fgTpWCEQxx2PGY4wj085iBG-vNzAx33bZ1ZqgORcdX0S0g@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-sN5Kc5_W07iSKvZqSz_cNu50rkoQ65cP3_bWeFNcyizA@mail.gmail.com>

On Wed, Dec 9, 2015 at 6:59 AM, Mark Friedenbach <mark@friedenbach.org> wrote:
> Greg, if you have actual data showing that putting the commitment in the
> last transaction would be disruptive, and how disruptive, that would be
> appreciated. Of the mining hardware I have looked at, none of it cared at
> all what transactions other than the coinbase are. You need to provide a
> path to the coinbase for extranonce rolling, but the witness commitment
> wouldn't need to be updated.
>
> I'm sorry but it's not clear how this would be an incompatible upgrade,
> disruptive to anything other than the transaction selection code. Maybe I'm
> missing something? I'm not familiar with all the hardware or pooling setups
> out there.

I didn't comment on the transaction output. I have commented on
coinbase outputs and on a hard-fork.

Using an output in the last transaction would break the assumption
that you can truncate a block and still have a valid block. This is
used by some mining setups currently, because GBT does not generate
the coinbase transaction and so cannot know its size; and you may have
to drop the last transaction(s) to make room for it.

That a block can be truncated and still result in a valid block also
seems like a useful property to me.

If the input for that transaction is supposed to be generated from a
coinbase output some blocks earlier, then this may again run into
hardware output constraints in coinbase transactions. (But it may be
better since it wouldn't matter which output created it.). This could
likely be escaped by creating a zero value output only once and just
rolling it forward.


  reply	other threads:[~2015-12-09  7:17 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07 22:02 [bitcoin-dev] Capacity increases for the Bitcoin system Gregory Maxwell
2015-12-07 22:54 ` Bryan Bishop
2015-12-08  2:42 ` Anthony Towns
2015-12-08  4:58   ` Anthony Towns
2015-12-08  5:21     ` Gregory Maxwell
2015-12-08  6:54       ` Anthony Towns
2016-01-18 12:02     ` Anthony Towns
2016-01-22  9:46       ` Anthony Towns
2015-12-08 11:07 ` Wladimir J. van der Laan
2015-12-08 11:14   ` Jorge Timón
2015-12-08 15:12     ` Gavin Andresen
2015-12-08 15:55       ` Justus Ranvier
2015-12-08 17:41         ` Mark Friedenbach
2015-12-08 18:43           ` Justus Ranvier
2015-12-08 19:08           ` Tier Nolan
2015-12-08 19:31         ` Gregory Maxwell
2015-12-08 23:40         ` Jonathan Toomim
2015-12-08 23:48           ` Luke Dashjr
2015-12-09  0:54             ` Jonathan Toomim
2015-12-08 23:50           ` Jorge Timón
2015-12-09  0:56             ` Jonathan Toomim
2015-12-08 23:59       ` Gregory Maxwell
2015-12-09  0:58         ` Jorge Timón
2015-12-09  1:02           ` Jorge Timón
2015-12-09  1:09         ` Gavin Andresen
2015-12-09  1:31           ` Gregory Maxwell
2015-12-09  4:44             ` Ryan Butler
2015-12-09  6:29               ` Gregory Maxwell
2015-12-09  6:36                 ` Ryan Butler
2015-12-09  6:59                 ` Mark Friedenbach
2015-12-09  7:17                   ` Gregory Maxwell [this message]
2015-12-09  7:54                 ` Jorge Timón
2015-12-09  8:03                   ` Gregory Maxwell
2015-12-09  8:46                     ` Mark Friedenbach
2015-12-09 11:08                     ` Jorge Timón
2015-12-09 16:40                     ` Gavin Andresen
2015-12-11 16:18                       ` Jorge Timón
2015-12-11 16:43                         ` Gavin Andresen
2015-12-12  5:13                           ` digitsu
2015-12-12 15:18                             ` Mark Friedenbach
2015-12-14 11:21                               ` Jonathan Toomim
2015-12-14 12:44                                 ` Adam Back
2015-12-09  4:51             ` Anthony Towns
2015-12-09 14:51       ` Chris
     [not found]   ` <CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
     [not found]     ` <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
2015-12-21  4:33       ` Pieter Wuille
2015-12-21  4:42         ` Justus Ranvier
2015-12-21  4:44         ` Alex Morcos
2015-12-21  4:50         ` Mark Friedenbach
2015-12-21  5:29           ` Douglas Roark
2015-12-21  5:21         ` Btc Drak
2015-12-21  8:07           ` Anthony Towns
2015-12-21  9:56             ` Jorge Timón
2015-12-08 23:48 ` Jonathan Toomim
2015-12-09  0:23   ` Gregory Maxwell
     [not found]   ` <CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
2015-12-09  0:40     ` Jonathan Toomim
2015-12-09 12:28 Daniele Pinna

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=CAAS2fgTpWCEQxx2PGY4wj085iBG-vNzAx33bZ1ZqgORcdX0S0g@mail.gmail.com \
    --to=greg@xiph.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mark@friedenbach.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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