Isolation verification, a hard fork ?
-
The same transaction can generate two tx_id, so detached signature from TX_IN and TX_OUT, modify the calculation rule for the block size. A block will contain more deals.
I think bitcoin core is superior to bitcoin classic.
-
Is that feature well tested, stable and secure?
-
I like the idea of the additional blocksize, I thought it was well tested and probably a good idea, interesting that there are other features that might cause issues.
Is there a list of Bitcoin Core features, that will need a hard fork?
-
Well the change to 0.11.2 in itself is a hard fork, as soon as the new block version is enforced, what will happen when more than 99.x% of online wallets is on 0.11.2
First information about compatibility can be found here: https://bitcoin.org/en/release/v0.11.2
-
What I’m trying to make sure is we don’t end up with 2 hard forks, e.g. an unwanted feature is sneaked in and we want to regress…
The Bitcoin Core does look pretty neat though, and some of the issues (like having a hard fork) looks like they are being addressed.
-
I didn’t understand this paragraph from BIP 113, that might effect pools. I assume p2pool head will have included a fix…
Implication for users:
GetMedianTimePast() always trails behind the current time, so a transaction locktime set to the present time will be rejected by nodes running this release until the median time moves forward. To compensate, subtract one hour (3,600 seconds) from your locktimes to allow those transactions to be included in mempools at approximately the expected time.
