Create account

1720d
What I don't like about BUIP143 is that some BU devs want it to give them "carte blanche" to do a soft-fork against donation addresses.

I'm not at all sure that's needed, or a prudent countermeasure.

My thoughts

1/
sickpig
replied 1720d
Agreed on both main points you made. Blacklisting would be near impossible to implement *and* it introduces a new validation criteria as IFP proposal would have had.
sickpig
replied 1720d
BUIP143 may have had an effect in helping IFP proponents to re-evaluate, thou
replied 1720d
oh yes, definitely
replied 1720d
There is another major point, which occurred to me, which I will add as item 11/
replied 1720d
I know the IFP proposal seems to be losing support, but let's examine theoretically if BTC.top & others went ahead and set up their plan & code in ABC to pay to a HK fund address.

2/
replied 1720d
Now imagine BU sets up their code using BUIP143 as justification to soft-fork in a rule which orphans any blocks containing the "HK fund address(es)" advertised in ABC code.

3/
replied 1720d
A lot has been said about "optics" of the IFP proposal (tax-like, non-debate theory etc).

But what about the optics of adding a address-based blacklist to BCH (BU) code?
Not good!

4/
replied 1720d
If we want to keep a "tax free", non-discriminatory incentive structure on BCH, I'm not for such a blacklist, and I am contemplating putting up a counter-BUIP to express that.

5/
replied 1720d
Blacklists don't work well.

"The cartel" could make their code have a flexible mechanism, distributing "approved" donation addresses among their members (pools, exchanges etc).

6/
replied 1720d
One possible BU defense would be a further SF to restrict CB outputs to a address, but I'm sure you can see how that would be another bad move (think existing donations & optics).

7/
replied 1720d
As I see it, such soft-forks would work against the ideals of BU to bolster and not to degrade the existing p2p cash system.

8/
replied 1720d
I opened another BUIP, it would ask to release a May version that contains any non-controversial updates, but simply not include orphaning based on some involuntary CB payouts.

9/
replied 1720d
In other words, to do on BU what this article is proposing to do with the ABC codebase in such a case:

https://read.cash/@SharkySharkdog/you-lead-and-maybe-i-will-follow-ff383504

10/
replied 1720d
Finally, another major reason not to go down the road to blacklisting any coinbase outputs:

I believe it would open the door to more requests from regulators / governments. Eeek.

11/
replied 1720d
Link to Memo poll on whether I should open another BUIP unless BUIP143 is amended.

https://memo.cash/post/05213910f1d09a05b781efaa75f12b1d8352ee99b58db70942c6c33a966845e6

12/
sickpig
replied 1720d
makes sense to make it explicit but to my eyes this come bundle w/ blacklisting. You basically introduce a precedent and remove plausible deniability when it will be most needed.
replied 1719d
After discussion on the BU forum re: BUIP143, I've received a statement from Greg Griffith that "blacklisting addresses was [...] not on the table".

This puts me a bit more at rest.