bitcoincashorg / spec Goto Github PK

Strong suggestion:
N=50. This needs a slight adjustment to sum(solvetimes) to be multiplied by 1.01 to keep solvetime more correctly on track. If two bad forward stamps in 3 occur as on accident or 50% miner, D can be sent down by 1-(50/62) = 20% (verses 8% for N=144). This will be immediately erased with the next honest timestamp. This is an argument for not going below 50.

There is concern about miner profit motivation and N=144 potentially having oscillations due to this. Those oscillations will not get out of hand. It happens in all diff algos. You can't put a filter on it to fix it. I've explained the theoretical reasons why filters don't work.

You'll get the same delays per block with N=50 and maybe even a little worse, but instead of 30 or 40 blocks with long delays, you'll have only 10 to 15 (with N=50). Low N is just to make these cycles happen faster and more frequently so any given post-attack delays are not long. Lower N allows price and difficulty to stay closer in sync. That's the key to my email yesterday when I showed N=144 is 12 hours behind, while Degnr8's WT with N=50 is only about 3 hours behind. You still might have 90 minute delays at times, but they will be for only 10 blocks instead of 40. And really, on the mainnet it won't be that bad.

I have a fix for this. I didn't mention it because I've been busy trying to convince everyone to get off the large N.

CoinReward = BaseReward * avg ( past N solvetimes) avg (past 2N solvetimes)

Ta-da. This solves all other difficulty problems. I call this Zawy v5, but now I've got to call it something else to use Degnr8's WT. I need to mention Tim Olsen suggested the general idea of modifying coin reward based on difficulty, and karbowanek coin reminded me. The interesting thing is that coin reward release stays perfectly on time. I sort of guessed at the 2N part. I like the results so well I have not tried anything else. An interesting aspect is that if solvetimes start getting out of the 100-block average, the rewards or punishes miners to get it back on track.

The chart below shows the results with WT=50. The magenta line is coin reward per difficulty. Notice that the attackers begin when the reward/difficulty is the highest, the best time to get profit. But notice how it collapses as soon as they begin an attack.

Getting back to possible complaints about the current simple algo under proposal:

The total time limits 2x and 1/2 are merely not needed, so they're not bad.

WT would be better, but I'll acquiesce on that.

Argument for what median of 3 is not needed, but I'm OK with it:
The median of 3 prevents all damage from bad timestamps as long as it's not a > 50% attack and as long as they do not do anything else to block negative solvetimes or reverse timestamps. This comes at a cost of being 1 block slow all the rest of the times where there is not a timestamp error. So with or without the median of 3, it's good, as long as nothing else is changed. For example (max-min) on N timestamps like many coins do is not optimal like sticking with (last-first).

via https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000513.html

Please consider reserving a few extra bytes, as part of either the

• address type
• or the payload.

This would help future-proof the address format for new features which wallets can choose to implement.

How these bytes are used can be specified by the community at a later date.

One example is address flags.

As implemented in the CoinSpark colored coin protocol, address flags [1] help sending wallets know what features the recipient's wallet supports.

For example, if the sender is transferring OP_RETURN based assets, the sending wallet can verify that the recipient's address supports assets, to avoid a non-supporting wallet from accidentally sending on those assets.

Another example is a feature like out-of-band messaging, where not all wallets support messaging, so the sending wallet would only enable the message UI field if the recipient address indicated it supported messages.

[1] https://coinspark.org/developers/coinspark-addresses/

I'm looking for some help to convert between legacy (base58) and cashaddr (base32) in node.js for a Discord bot. Anyone have example code? They're all P2PKH addresses generated by Bitcoin ABC.

Issue: abrkn/shilly#40

Hi, as I'm holding BTC+BCH myself, please take care of my concerns of the compatibility between CashAddr and Bitcoin Addr:

By compatible, I mean a CashAddr can be converted into Bitcoin Address (ClassicAddr)
which is available to receive BTC, in this case the ClassicAddr and CashAddr shares
the same private key.

If a CashAddr and CassicAddr is compatible at that level, a tool can be created for
generating CashAddr or ClassicAddr on user's behalf.

Well the coolest idea is that CashAddr can be directly converted into ClassicAddr or
vise versa. In this case the CashAddr will be great upgrade!

It will bring inconveniences to me if such an compatibility is impossible!

Why would you not specify how you calculate the 160 bit hash value which goes into the standard format of a Bitcoin Cash address? To anyone looking, the answer is the same as that for Bitcoin: Ripemd160(Sha256(public key)).

windows knows how to send bitcoin:address hyperlinks to your wallet program, like electrum.

is the right thing to do on websites provide
<a href="bitcoin:13RWiPzQhv2s7xnF7XM1PifRJcbdqYHMbM">

or will it be
<a href="bitcoincash:qq04kymfcr2a40dzt0exaqk5n8yd8ymsxgn277rhe9">
or even
<a href="bitcoin:bitcoincash:qq04kymfcr2a40dzt0exaqk5n8yd8ymsxgn277rhe9">

Hi all,

Want to get ahead of the bitcoin cash address change, glad to see it's happening at last. I wanted to ask about the specification, as reading it, I can see there are indeed a couple of differences with bip173. So far yet to get my code reproducing test fixtures, but had some comments following a review of it vs bip173

If you check this line, it looks like a possible bug in the spec (though happy to have my error pointed out): https://github.com/Bitcoin-UAHF/spec/blame/master/cashaddr.md#L87

How could the final condition ever be true? ah, I guess by that point c can have all bits set, nevermind.

I was confused about why the field constants were changed at all - just means having to add more parameters to a bech32 implementation (the field constants, CSLEN and SEPARATOR from what I can tell) or just duplicate the whole thing.

Another minor point about the choice of ":" for the separator - double clicking the addresses will only select one half of it.. I think this should be a consideration whilst selecting characters for an address humans copy/paste around, but at the end of the day it's only a usability issue.

The new proposed cashaddress format meets a valid need: that is, a way to disambiguate UAHF addresses from BTC core addresses to enhance the user experience and increase adoption.

However, the current proposal goes in the opposite direction, and will likely result in more confusion.

The rest of the cryptocurrency world has adopted a convention that addresses contain a simple version prefix which identifies the coin when the hash160 of the public key is taken. This results in a specific letter prefix that serves to identify the user which coin is currently in use.

While there are some problems with that approach, users, wallets, URIs, and software libraries have standardized on that approach after 5 years of development. A VERY large amount of multi-coin and wallet software and exchange software relies on that convention. Furthermore, Users have come to recognize this format as what a crypto address "looks like" and have begun to associate it with cryptocurrency. It's what they look for on payment pages and what they think of when they try to find their address.

A radical departure from that convention (such as the current proposal) will likely be difficult to follow and difficult to integrate by maintainers, resulting in a low adoption rate.

Low adoption rate actually makes the problem worse than the status quo. If there is a low but non-zero adoption rate of this standard, then ALL wallet software or exchange software that interacts with the BCH chain will need to be re-written and upgraded in order to not introduce bugs. Since some will not, it will become necessary to suppot both standards for a very long length of time.

Worse, it will be even MORE confusing to users than a simple format change would be, especially if only a small fraction of wallets use it.

Although I'm not a fan of Bitpay's approach to BCH addresses because it's non-standard, it's VASTLY superior to this proposal in almost every way.

It can't succeed without reference implementations.

Are there any other reference implementations than bchutil?

(Taking into account that Core's bech32 has 9 implementations)

The forkid version change effects the replay protected sighash. The forkid change for the may 2018 hardfork is specified to "not be implemented for wallets". Does that mean that sighashes will be different based on whether the compiled code is a fullnode or a wallet? How will transactions verify? It seems that if I create a transaction and sign it using a wallet that is using the old forkid, then try to broadcast or relay the transaction using a Full node that has a new forkid, the signature hash will be different and the transaction will not relay or verify.

It seems like this requirement makes no sense/is ambiguous then, because if a wallet makes a different sighash than a node, then it will become incompatible.

How is this supposed to be implemented?

Side question: why is it necessary to update the forkid for the sighash at all here? It doesn't seem necessary for all hardforks. We needed to change the sighash for the btc hardfork because the hardfork was contentious and we were trying to achieve a chain split....but since we explicitly want to avoid a chain split in may2018 why wouldn't we just rely on Nakomoto consensus?

It seems unsustainable and buggy to continually update the forkid on every hardfork. It will introduce an exponential amount of work to maintain block explorers, wallets, and other libraries to compensate.
I'm concerned that it will tax engineering resources to develop the ecosystem or even could result in bugs that will lose user funds.

While doing https://github.com/Ayms/cashaddress I found the following section not so clear:

"The checksum is calculated over the following data:

The lower 5 bits of each characters of the prefix.
A zero for the separator (5 zero bits).
The payload by chunks of 5 bits. The payload is padded with zero bits up to the point where it is a multiple of 5 bits."

I would modify it by:

"The checksum is calculated over the following data:

The lower 5 bits of each characters of the prefix.
A zero for the separator (5 zero bits).
The payload by chunks of 5 bits. The payload is padded with zero bits (on the right) up to the point where it is a multiple of 5 bits.
A 40 bits null checksum with all bits set to 0"

This isn't an issue that needs resolving. I just didn't know of a better place to put this.

I'll post an updates in this thread.

It looks like the DAA will work well. After an initial problem due to starting at a level much lower than optimal (not shown because it was < 144 blocks), it overshot the difficulty and caused a period of only 8 blocks in 6 hours (shown as the peak on left). Then it went through a period of 2.5x more blocks than target for 4 hours (period where blue time line is below the green line). Now due to a lowering in price, it is overshooting the difficulty a little bit.

It takes it about 50 blocks before it responded to an obvious need to increase difficulty. This caused it to overshoot. Hopefully the severity in the first cycle will not be seen again, unless price changes abruptly.
There are 3 elements that will cause oscillations in the future: price changes combined with the large N that causes price to be about 70 blocks ahead of difficulty, and miners having the option to go back to a larger coin (BTC). These three things combined will cause oscillations that are beyond the statistical expectation. A 4th thing is not a root cause but it greatly amplifies the effect: miners non-linearly jumping on and off the coin. By that I mean a 30% disconnect between price and difficulty (i.e. difficulty is 30% too high or too low as a result of being too slow from large N=144) causes a 300% change in hashpower.

I'm surprised to see how much miners jump on when it goes 25% below their target difficulty. Hashpower increases 200% (3x more mining). It seems to take an overshoot of 40% to go to 1/3 the correct difficulty.

The target difficulty line is 0.80 x (BTC difficulty) / (BCH price in BTC). There were 2 times where solvetime appeared correct, which is how I came up with the 0.80 factor. So it appears miners are "20% less enthusiastic" about BCH compared to BTC, for a given price.

Instead of 8 bits for version, split in 1 (reserved) + 4 (type) + 3 (size) bits, maybe we should use instead a total of 10 bits, to make it boundary aligned with the character division of 5 bits each.

Te meaning could be 1 (reserved) + 4 (type) + 5 (size, optional?, could be ommited if type is not P2SH).

Since the prefix is part of the checksum, the spec should explicitly state if the prefix must be lowercase or whether its okay to be mixed case, in the event that the checksum computation will convert the prefix to one of the cases.

An example makes it easier and faster to check that the code has been implemented correctly.
Several examples are provided https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki, perhaps one or more of these examples could be translated to Bitcoin Cash?

I've compiled all the Opcodes that Bitcoin Cash should have, to make it easier to decide.

Satoshi's removed script commands:
OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT

OP_INVERT, OP_AND, OP_OR, OP_XOR

OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD

OP_LSHIFT, OP_RSHIFT

(For reference purposes, those are already implemented here: https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp)

Now here are the innovative ones

OP_DATASIGVERIFY:

This script basically does what OP_CHECKSIGVERIFY does, but it does it for data on the stack rather than for the transaction. Specifically, it pops the top 3 items off the stack, the pubkeyhash, the signature, and some data and verifies that the signature is valid for the provided data and that the signature’s public key hashes to pubkeyhash. If this is invalid the transaction validation fails. If it validates the data is pushed back onto the stack for use by the rest of the script.

Description: https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9

OP_MERKLEBRANCHVERIFY: The combination of BIP 116 and BIP 117 yields MAST script, which would make Bitcoin's script 2.0

Implementations: https://github.com/maaku/bitcoin/tree/merkle-branch-verify
https://github.com/maaku/bitcoin/tree/tail-call-semantics

OP_GROUP (too early for the may hardfork?): Simple tokens: https://bitco.in/forum/threads/buip077-enable-representative-tokens-via-op_group-on-bitcoin-cash.7501/

Have I missed something?

Use of "Payload" is ambiguous as it's defined in spec as a base32-encoded data stream containing the version byte, hash, and checksum. It should be more clear that the data being calculated is the version byte, hash, and zeroes for the checksum rather than simply saying item 3 is payload and item 4 is zeroes for the checksum. It's likely new developers will not include the version byte given the wording of the current spec, assuming "payload" to mean "key hash".
It would also be useful to clarify that while every number is limited to 5 bits, they still each use up all 8 bits (with the exception of the chunked payload), with three empty spacer bits per byte. The "5 zero bits" and "Eight zeroes" wording is extremely confusing. Either describe it as an array of bytes with the prefix cut down to the lower 5 bits of each letter and the payload reorganized in 5-bit chunks, or describe it as an array of 5-bit values stored in isomorphic bytes. Using 5-bits and bytes together is just mean to the reader.
Finally, the fact that the hash should be base32-encoded separately from the payload would seem to be of vital importance, both for encoding and decoding. This seems to be glossed over. It should also be mentioned for verification purposes that the last 8 base-32 encoded characters are the hash, which should be removed from the address before splitting into prefix and payload. All the pieces of the definition are there, in a way, but they're not set out as clearly as they should be.

The first and last problem can both be solved by improving the definition of Payload to mean the Version Byte and Key Hash, and defining the Checksum as a suffix to the address entire, rather than trying to say that the Checksum is part of the Payload and that it's all one stream of base-32 encoded data. It's not one stream, it's two.

Maybe base32 could also be used for export and import of private keys. It can deal with 256 bit data, so why not also use it for that?

This makes no sense:
The payload is composed of 3 elements:

A version byte indicating the type of address.
A hash.
A 40 bits checksum.

Then

The checksum is calculated over the following data:

The lower 5 bits of each characters of the prefix.
A zero for the separator (5 zero bits).
The payload by chunks of 5 bits. The payload is padded with zero bits up to the point where it is a multiple of 5 bits.

How can the checksum be calculated over itself?