From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C6CFFAAC for ; Fri, 14 Jul 2017 18:44:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6EBA5AD for ; Fri, 14 Jul 2017 18:44:08 +0000 (UTC) Received: by mail-qt0-f171.google.com with SMTP id i2so68988751qta.3 for ; Fri, 14 Jul 2017 11:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=2vmsB1cxjvvR3sIb6xN72CbZtz5GYwJByJt1H23TsSo=; b=F1ey790rbgGz72FvRa2PuwsQhCpYaS9txdGOCwILq2IRNU0N6Hw/eLsl+Q/S6Zl3L/ wQ9XAMpUlSnVj9C/AbyVshZuyqNBEiTy2gBAPV9izLa/ixr2P6lLeJEQLBPCO8VpO2jj CTFWUx5za2NbI01d82m1UzpmrIXz6rvhGlG43EhxDTkrH/V73Y0GaQE0bkJkqA8hjbzk tUKFV+ZGMmCwcOdIQXNOAsTUweUA3j2Kvy86vQitr8eqv+wnHIYNY0kYQ0QqXq22Ciu3 ibmg9drss4NuO5th6xvs3hx2Xngnv71cy9XUvJJjzGwYQ/VbTO7QmjumkqVCjfu1mdXm MFpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=2vmsB1cxjvvR3sIb6xN72CbZtz5GYwJByJt1H23TsSo=; b=EfhICdU+pA78stJN/ax2Z9zl4TCr1W569TkGccT7Ii85C4777zsPp15a2zpPvEFS/j srtdImtTvnMtXarsLKduBq3l0VMywvCroEXj4yweKDRD9Gt/JWTvHf8/7gi9mFCGoODx LEa5pUtjL5WOeBAFy0Lx80Sy56i8z4lZTp+VI0uqucVrCOvbh3xYQJ7dUaIAr5PEEDsq 78le0szOIfBfPmoVUIHo8hJtw+w/Qmq84K/CWNGesEhK6qADi6aZPQsNQxaS7vPFotLv +XjJO2W67kq2bQf/vvgLikYe5i1MPNm9+ql37q1uDo2prPsXLEVAzA00TEpc1NsP5Nqr aRuw== X-Gm-Message-State: AIVw110NSbGcjulopyyNlZ5C6GAVmp10dbTnfGXoH/qnHIWbBPed6HZa 150QJngFQg6v8EvKeLEqm1hDnWojubfS09c= X-Received: by 10.237.47.132 with SMTP id m4mr12812717qtd.200.1500057847474; Fri, 14 Jul 2017 11:44:07 -0700 (PDT) MIME-Version: 1.0 Sender: clarkmoody@gmail.com Received: by 10.12.146.216 with HTTP; Fri, 14 Jul 2017 11:43:37 -0700 (PDT) From: Clark Moody Date: Fri, 14 Jul 2017 13:43:37 -0500 X-Google-Sender-Auth: 1UBItfuMcdjnCd2GFNz12IwHtHY Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 14 Jul 2017 18:48:45 +0000 Subject: Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 18:44:08 -0000 (copying from GitHub per jonasschnelli's request) I can understand the desire to keep all reference strings to the nice 14-character version by keeping the data payload to 40 bits, but it seems to place artificial limitations on the format (year 2048 & 8191 transactions). I also understand that this might be addressed with Version 1 encoding. But current blocks are not that far from having 8191 transactions. You could go with a variable-length encoding similar to Bitcoin's variable ints and gain the benefit of having a format that will work for very large blocks and the very far future. Also, the Bech32 reference libraries allow encoding from byte arrays into the base-5 arrays native to Bech32. It seems like bit-packing to these 40 bits might be overkill. As an alternative you could have one bit-packed byte to start: # First two bits are the protocol version, supporting values 0-3 V = ((protocol version) & 0x03) << 6 # Next two bits are magic for the blockchain # 0x00 = Bitcoin # 0x01 = Testnet3 # 0x02 = Byte1 is another coin's magic code (gives 256 options) # 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options) M = (magic & 0x03) << 4 # Next two bits are the byte length of the block reference B = ((byte length of block reference) & 0x03) << 2 # Final two bits are the byte length of the transaction index T = ((byte length of transaction index) & 0x03) # Assemble into the first byte Byte0 = V | M | B | T This gives you up to 3 bytes for each block and transaction reference, which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots. Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx reference bytes] So the shortest data part would have 3 bytes in it, with the reference version 0 genesis coinbase transaction having data part 0x050000. I know this is a departure from your vision, but it would be much more flexible for the long term. Clark