< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #10537: Few Minor per-utxo assert-semantics re-adds and tweak (master...2017-06-per-utxo-fixes) https://github.com/bitcoin/bitcoin/pull/10537
< da2ce7_>
Good Morning -core-dev. I have a draft-mailing list post that I would like some pre-posting review.
< da2ce7_>
Wallet and Exchange Proposal Best Practices for Schism Forks
< da2ce7_>
* Proposed Wallet and Exchange Best Practices for the case of Schism Forks
< luke-jr>
da2ce7_: I disagree that softforks can be the *cause* of a schism fork. In the case of BIP148, for example, the split is caused by miners violating the protocol rules. This is really no different than a split when the rule isn't newly added.
< luke-jr>
and if nodes wilfully choose to follow the invalid chain, that removal of the rule is an attempted hardfork (and probably contentious)
< da2ce7_>
Yes, miners can choose to cause a schism fork at any time if they wish to use checkpoints, the soft-fork is just an excuse.
< luke-jr>
"pre-schism tokens" should be defined. Does it mean a UTXO valid on all chains? (or better, for fungibility, a claim to the same amount on all chains)
< luke-jr>
da2ce7_: checkpoints are not needed either; they could for example choose to mine a larger-than-allowed subsidy
< da2ce7_>
If we had evil-softfork implemented by the miners, then users could choose to create a schism to to reject this soft-forkl
< da2ce7_>
Yes. I agree that the pre-schism tokens should be more-well-defined.
< luke-jr>
evilforks aren't softforks :p
< da2ce7_>
Maybe the virtual tokens should be something like 'spendable balance' on both chains. (utxo outputs, minus fees required to spend). So if somebody deposits 10000x small outputs is doesn't unbalance the pair.
< luke-jr>
da2ce7_: what if Joe Schmo makes a schism fork of his own and doesn't tell exchanges? they owe JoeSchmocoins?
< da2ce7_>
yes, we need some significance clause in the document.
< luke-jr>
"Make sure that transaction replay protection has been implemented." I disagree this should be the standard case. If people want to withdraw "pre-schism tokens", replay should be intentionally enabled if anything.
< da2ce7_>
no. you are forbidden to withdrawal pre-schism virtual tokens.
< luke-jr>
that's dumb :P
< luke-jr>
"Withdrawals MUST only be enabled until transaction relay protection has been added for both sides of the schism." <-- doesn't make sense
< da2ce7_>
they don't exist. They are only virtually exist for accounting purposes.
< luke-jr>
da2ce7_: before the schism, all withdrawls are pre-schism tokens
< da2ce7_>
yup. post-schism pre-schism tokens don't exist. Only their virtual counterparts exist.
< luke-jr>
the ideal for a neutral merchant/user is to wait for receives to confirm on both chains; this is only possible if replay is standard
< da2ce7_>
Ok... I'll rephrase that part.
< luke-jr>
preventing replay should only be done when the sender and recipient are taking a position
< da2ce7_>
luke-jr no, because there are all sorts of attacks that may happen. For example, it may be not the same transaction that confirms because of transaction malleability.
< luke-jr>
I don't see how that's a concern
< luke-jr>
if I'm expecting a payment, and I have no bias as to which side of the schism, I simply wait for it to confirm on both sides. txids don't matter
< luke-jr>
otoh, I guess if we assume market values on each side will differ, perhaps this neutral ideal is impractical
< da2ce7_>
only if you are dealing with pre-schism tokens exclusively. However I wish make it clear to the users that there is now indeed two distinct coins, if they love that fact or not is besides the point.
< CypherBlock>
What would people think of a bip to start rejecting segwit signaling blocks, starting on Aug 1? This is a safety mechanism to prevent reorg and segwit will not activate naturally anyway. So it is a forced unarming of segwit. Thoughts?
< wumpus>
I'm going to tag 0.14.2rc2 in a bit - anything that needs to get in?
< bitcoin-git>
bitcoin/0.14 5e408d9 Wladimir J. van der Laan: doc: Update manpages for 0.14.2
< BlueMatt>
k
< wumpus>
(I mean the prefixes are introduced to distinguish it from locals, or class variables, etc, which is just as valid for something static)
< BlueMatt>
makes sense
< bitcoin-git>
[bitcoin] laanwj opened pull request #10539: doc: Mention update manpages in release process (master...2017_06_release_process_manpage_update) https://github.com/bitcoin/bitcoin/pull/10539
< wumpus>
ok, going to tag 0.14.2rc2 then
< wumpus>
* [new tag] v0.14.2rc2 -> v0.14.2rc2
< bitcoin-git>
[bitcoin] laanwj closed pull request #10539: doc: Mention update manpages in release process (master...2017_06_release_process_manpage_update) https://github.com/bitcoin/bitcoin/pull/10539
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10540: Salvage wallet should not set the aggressive flag on Db::verify() (master...fixsalvage) https://github.com/bitcoin/bitcoin/pull/10540
< bitcoin-git>
bitcoin/master 24980a3 Mario Dian: Make functions in validation.cpp static and pass chainparams...
< bitcoin-git>
bitcoin/master 1b708f2 Wladimir J. van der Laan: Merge #10201: pass Consensus::Params& to functions in validation.cpp and make them static...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10201: pass Consensus::Params& to functions in validation.cpp and make them static (master...consensusparams-receivedblocktransactions) https://github.com/bitcoin/bitcoin/pull/10201
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10545: Use list initialization (C++11) for maps/vectors instead of boost::assign::map_list_of/list_of (master...list_of) https://github.com/bitcoin/bitcoin/pull/10545