[Bitcoin-ml] Alternative proposal for a Bitcoin Cash address format

Chris Pacia ctpacia at gmail.com
Sun Dec 31 20:20:29 UTC 2017


I think one of the main benefits of bech32 is speed versus base58. The 
cashaddr spec also includes a type field for extensibility.


On 12/28/2017 03:29 PM, Steve Davis via bitcoin-ml wrote:
> I should briefly mention that the ECC is calculated over the prefix 
> (0x014ced which B58 encodes to "BCH" for this address length) and the 
> PK hash.
>
> On Thu, Dec 28, 2017 at 2:20 PM, Steve Davis <steve at solarbit.cc 
> <mailto:steve at solarbit.cc>> wrote:
>
>
>     All,
>
>     Prior to committing to a bech32 based format I'd like to make an
>     initial proposal that I feel is more obvious and familiar for
>     users, utilizes libraries that are already used by QR code
>     generation, and so may be easier and less error-prone to implement
>     for wallet developers.
>
>     I've not really done more than a preliminary assessment but the
>     basic format proposal is this:
>
>     Ticker Prefix + PK Hash + ReedSolomon ECC "Checksum" (a BCH code
>     special case)
>
>     Example:
>
>     For a payload = 0x98ccb085ce5a5affc4f54bb032a48fd2fa2b840a
>     (RIPEMD160 hash of ECDH256 Public Key)
>     ECC/Checksum = 0xd16b4f5b (Reusing QR's prime modulus of 285 over
>     a GF256 field to generate an ECC of degree 4, i.e. 4 bytes)
>
>     Address bytes =
>     0x014ced98ccb085ce5a5affc4f54bb032a48fd2fa2b840ad16b4f5b
>     Base58 encoded = BCHc8e231kbH9SidCGh4Jv3tTxiw3QPsPtcr (36 characters)
>     The syndrome for this is [0, 0, 0, 0].
>
>     Flip a character: BCHc8e231kbH93idCGh4Jv3tTxiw3QPsPtcr
>     The syndrome is [72,82,28,139] indicating error (and likely position)
>
>     Flip a bit: 0x014ced98ccb085ce5a5bffc4f54bb032a48fd2fa2b840ad16b4f5b
>     The syndrome is [1,152,78,10] indicating error (and likely position)
>
>     Yes this is all _very preliminary_, but I thought I'd get in there
>     before we committed to bech32 which seems, well, ugly and
>     unfamiliar to me as a user and also introduces new code complexity
>     for pretty much every client implementation of BCH and wondered if
>     others here think the above idea has enough legs to be worth
>     pursuing further.
>
>     /s
>
>
>
>
> -- 
>
> <http://www.solarbit.cc/>
>
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171231/6a8be6ae/attachment.html>


More information about the bitcoin-ml mailing list