Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8B7E53EE for ; Sat, 25 Jul 2015 22:05:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D4F03DE for ; Sat, 25 Jul 2015 22:05:29 +0000 (UTC) Received: by wicmv11 with SMTP id mv11so98268683wic.0 for ; Sat, 25 Jul 2015 15:05:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=imVCzOS1O3SsTGo38c83/zfbsWR1JVONsx7ki8ARQCg=; b=Vhg2ChVHOaFwCek/aKQGoivqrH7QppEktXEGMYKu/8WHIUFxrg8icZgnwBXo43Lnf7 jRYUHtGKySBtuGJ+wPTcueXvf2PQ2VZpkKEcFx8IxMmkURepFTsFAz4fXIMwrtQl4hJs JDr0RMY74ckPMil4uS4MUH//kN6ssfOProumb6TZfSAkgNi4VamUDePEeaA9q0DrDJKQ NNI92nVYflOzDw/aSpqTgtK5mfibngVNyK1T+RUrJ6N6GO/O+W8GNA4NP8T5KXNY6R2z yYVIhAwysopygWSlFtIG6qgCJTIk5ysKv0JIPVhZGSFbnsmbNh9bpgo95O6sqrnO4+T4 QLPg== X-Gm-Message-State: ALoCoQkblT+aGyLh6Rx2yNoo9Vu1y2xIcJ/taiFXnimAm20qVF5enQusEeKgPE4m3crUVxWDGeKk MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr39672516wjc.26.1437861928295; Sat, 25 Jul 2015 15:05:28 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Sat, 25 Jul 2015 15:05:28 -0700 (PDT) In-Reply-To: <201507251951.53970.luke@dashjr.org> References: <201507251951.53970.luke@dashjr.org> Date: Sun, 26 Jul 2015 00:05:28 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke Dashjr Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP Draft: Minimum Viable TXIn Hash X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 22:05:30 -0000 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 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?