public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon•cc>
To: Luke Dashjr <luke@dashjr•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Draft: Minimum Viable TXIn Hash
Date: Sun, 26 Jul 2015 00:05:28 +0200	[thread overview]
Message-ID: <CABm2gDrCzYTo7hYB7EaVoDUq5bhD9TmMO=uGLn3H33Bz8J8ppg@mail.gmail.com> (raw)
In-Reply-To: <201507251951.53970.luke@dashjr.org>

From your draft:

"It could also more easily, ignoring the difficulties of a hard-fork
period, be rolled out as a hard fork to avoid hokey-pokey.[1]
[...]

[1] Because someone asked... The Txid Hokey Pokey: you put the tail
end in, you put the tail end out, you put the tail end in and you hash
it all about you do the hokey pokey and you solve the block difficulty
bound, that's what it's all about!"

Reading this, the first thing that comes to mind is "What the h#$% is
a hokey pokey?"

From https://en.wikipedia.org/wiki/Hokey_cokey : "It is well known in
English-speaking countries.".
That explains why I haven't heard about it in my whole life.
It may things clearer for people in these countries, but at least to
me, it just makes things more complicated: the analogy (that I still
don't understand after skimming the wikipedia article) doesn't allow
me to understand the actual explanation.

Can you please rewrite that with a more culturally-neutral analogy (or
just no analogy and just leave the explanation)?

On Sat, Jul 25, 2015 at 9:51 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thursday, July 23, 2015 8:12:19 PM Jeremy Rubin via bitcoin-dev wrote:
>
> This looks like just a p2p protocol optimisation, which doesn't even need a
> softfork. You do need to document the suggested protocol changes more
> specifically, however.

I think his goal is to make it a consensus change so that confirmed
transactions can also use less space in blocks.
But, yes, I don't think it gives you anything to enforce it as a
consensus rule (all you care about is the savings when transmitting
the transactions and blocks).
In fact, I'm not sure how would that work, would the "compact tx"
produce a different hash than the non-compact one?


      reply	other threads:[~2015-07-25 22:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-23 20:12 Jeremy Rubin
2015-07-25 19:51 ` Luke Dashjr
2015-07-25 22:05   ` Jorge Timón [this message]

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='CABm2gDrCzYTo7hYB7EaVoDUq5bhD9TmMO=uGLn3H33Bz8J8ppg@mail.gmail.com' \
    --to=jtimon@jtimon$(echo .)cc \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=luke@dashjr$(echo .)org \
    /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