Gold collapsing. Bitcoin UP.

[Christoph Bergmann]

Interesting talk.

However, the idea of a hash war is just bullshit.

ABC can split away with 1 percent of the hashpower and be listet on exchanges as BCH, and SV can survive with 1% of the hashpower, when it is listed on exchanges. With ABC softforking to a new transaction ordering algorithm, both chains will be incompatible. So, no, no hashwar. Maybe replay double spend war, but this will just destroy both chains.

 

[Norway]

Jimmy Nguyen is making a ton of sense in this talk.

 

[sickpig]

Completely different topic, but I feel it that needs mentioning.

The minimum fees that need to be paid for transactions are an important Schelling point.
We've already seen how fragmentation here can make 0-confirmation transactions more risky, i.e. increase risk of successful double spending.

I'm hoping that miners and developers of software clients will keep the economic aspect in mind here.

Increased complexity in fees is a deterrent to growth of the system. It requires increased complexity in a lot of software that merely wants to be able to send transactions.
We should really be aiming to keep things as simple as possible on the fee side to spur wide adoption.

Make it so that the minimum fees are always simply configurable by the node operators, so that in case of some drift in consensus, we can converge on a new Schelling point relatively quickly.

edit: this is an example of what @micropresident is working on
https://reviews.bitcoinabc.org/D1927

edit: this is an example take from @micropresident's work
https://reviews.bitcoinabc.org/D1927

---

Resist the urge to centrally plan new incentive or disincentive schemes.
Cheap, easy to understand transaction fees are the best tool we have in our fight against the competition AND increase the use of the chain, and they can already be used to encourage UTXO consolidation.
I see more need for wallets that do this for their users in safe but automatic or guided ways than new incentive schemes at the client layer.

@micropresident started already to work on a scheme that incentivize transactions that reduce the UTXO cardinality and "punish" txns that increase it. If memory serves he incentive is "implemented" via a change in the fee rate / priority structure. I don't know what's the status of his effort but I wonder what he has to say about your what you write in the post quote above.

 

[freetrader]

Turns out Bitcoin SV 0.1.0 raises the number of non-push opcodes in a script from 201 to 500.
Activation timestamp is the same as for ABC's 'magneticAnomaly' fork.

Release notes: https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v0.1.0

Would love to see the sustained 32MB or 128MB blocks with this release on a public testnet, but didn't see any new parameters for such in there.

 

[Norway]

@sickpig
It's probably best to let the market, not devs, find the fee price. With high tx volume and no production quota, it will probably be very stable. No schelling point needed.

And miners may advertise how they put a price on transactions. I wrote about this in this article where I even open the door for negative transaction fees:

https://www.yours.org/content/utxo-growth--solved-934c8a380558

 

[Norway]

Would love to see the sustained 32MB or 128MB blocks with this release on a public testnet, but didn't see any new parameters for such in there.

The Gigablock Testnet Initiative (GTI) should be open for all clients, open source and closed source, and different actors so they can test their hardware/software/internet connection. BU could charge a fee for this, but should not do KYC.

 

[Norway]

Daniel Krawisz has some interesting points on the talk of Jimmy Nguyen i posted above at the end of the interview. I'm sure @Mengerian will like it. (Starting at 1:08:50).

 

[Norway]

News update on @jtoomim :

"The fact that miners can form pools the size they want is a vulnerability in Bitcoin"

 

[Norway]

More @jtoomim news:

Here, he use @Peter R to defend the "fact" that internet has a capacity of 8 megabit:

 

[Norway]

@jtoomim history (not news):

It's impossible for an incentivized miner to send 1 megabyte of data through the great firewall of China in less than 17.4 seconds:

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1235#post-80109

 

[Christoph Bergmann]

Going from Nodecount,
https://cash.coin.dance/nodes

at least 1000 of 1885 BCH nodes are not prepared for the fork. Since nearly 600 of them are BUcash 1.3 nodes, they don't seem to care too much about regular updating. Is ABC willing to not just give up on community network effects with an unwanted hardfork, but also to lose more than half of the nodes?

 

[throwaway]

Those old nodes would be "lost" regardless, even without CTOR, because of DSV (and the other stuff). Would you still blame ABC then?

 

[Christoph Bergmann]

BU advocates for BIP135, which would give those old nodes at least 6 months before the upgrade kicks in.

 

[lunar]

Every vid these guys make is on the money.


Unfortunately For BU, DSV gets put through the wringer. DSV was unanimously voted in by BU, yet it's taken months for these concerns to arise. I think this shows one of the significant weaknesses in the BU voting system, (there are more) and highlights the gulf between those that implement the code, and how those changes are translated to others that perhaps have a better grasp of the economics.

As Ryan points out in this video

DSV is a massive change to Bitcoins economics. It's almost like every-time someone comes up with change to the code, it has unintended consequences.

As Ryan points out " I actually care about DataSigVerify, it's bad, because it's an artificial subsidy to what should be a very expensive operation."

We need to lock the protocol down ASAP. So the world can start building on a stable, economically sound, programable money.

Don't know who said this first but....​

"The price of Bitcoin is eternal vigilance."​

​

[doublepost=1539811889,1539811039][/doublepost]

at least 1000 of 1885 BCH nodes are not prepared for the fork. Since nearly 600 of them are BUcash 1.3 nodes, they don't seem to care too much about regular updating.

The Machiavellian in me wants to see a purge of all the absent minded non mining nodes, to give a clear demonstration of how bitcoin really works. (keep up, or shut up). Unless your non mining node, is hyper connected, such as exchanges and big businesses; it's at best a cumbersome wallet, and at worst, part of a weak sybill attack.

 

[Norway]

Great experiment and talk by @Peter R.

My takeaway is that doublespends are not a big problem, even for brick and mortar trades. POS solutions should probably just accept the transaction instantly, but monitor the network in the background and alert the merchant if something fishy is going on. No need for every customer to wait a few seconds for double spend control in the checkout process.

EDIT: I assume POS-solutions/wallets will have a bunch of nodes scattered around the earth if detection of doublespend attempts from a single node is difficult. Not sure if this was considered during the workshop or if the perspective was just on a single node.

 

[79b79aa8]

on the contrary, the Reverse Respend Attack, in which you broadcast a fraudulent non-standard transaction first, was successful 11% of the time. at such a rate, for important common cases, the party vulnerable to fraud must resort to mitigation.

case 1: online gambling
players send BCH to a dice site and have 94% chance to have their BCH + 4% earnings sent right back. with the Reverse Respend Attack, they play free roughly one time out of ten.


case 2: instant deposit to exchanges
it would be desirable for exchange customers to be granted instant deposit on their account: send BCH in, trade immediately. exchanges might want to remain competitive by offering the service.

this is out of the question with an 11% success rate on 0-conf, given that exchanges usually permit instant withdrawals. for all a thief has to do whenever his Reverse Respend is successful is pull out as soon as his account is credited, before the next confirmation. money doubled.

the exchange cannot protect itself by delaying the instant deposit transaction by some relatively short time span -- the time differential between the fraudulent and the seemingly honest tx is not key, the attack hinges rather on gaming the fee differentials between standard and non-standard txs.

in both of these cases, contracted transaction analysis is required, possibly supplemented with the adoption in wallets of scripted insurance schemes.

DSV is a massive change to Bitcoins economics. It's almost like every-time someone comes up with change to the code, it has unintended consequences.

but do consider @theZerg 's response.

 

[Norway]

@79b79aa8
The reverse respend attack should be easy to detect if you look for it, right?

I agree that gambling sites and exchanges should look for doublespends if they want to avoid fraud. But we are talking seconds here, right?

 

[MarkBLundeberg]

case 1: online gambling
players send BCH to a dice site and have 94% chance to have their BCH + 4% earnings sent right back. with the Reverse Respend Attack, they play free roughly one time out of ten.

I thought this was solved by just chaining their winnings on their unconfirmed UTXO? I suppose if the gambler can, after seeing the gamble result is a loss, then try to pull of a post-facto double spend to 'undo' a loss. Reverse respend not helpful here.

case 2: instant deposit to exchanges

it would be desirable for exchange customers to be granted instant deposit on their account: send BCH in, trade immediately. exchanges might want to remain competitive by offering the service.

Josh Ellithorpe's talk on exchange mitigation was quite interesting. It sounds like there are many solutions like just to put a hold on withdrawals and also take advantage that you have KYC. He thinks exchanges actually have it easy in many ways, compared to someone buying coffee and pulling off a reverse respend.

 

[79b79aa8]

The reverse respend attack should be easy to detect if you look for it, right?. . . But we are talking seconds here, right?

the fraudulent tx is easy to detect, but that's not the one the defrauded party sees. time between txs is not the main factor for success.

I thought this was solved by just chaining their winnings on their unconfirmed UTXO? I suppose if the gambler can, after seeing the gamble result is a loss, then try to pull of a post-facto double spend to 'undo' a loss. Reverse respend not helpful here.

ok

Josh Ellithorpe's talk on exchange mitigation was quite interesting. It sounds like there are many solutions like just to put a hold on withdrawals and also take advantage that you have KYC

didn't see that, but i would not touch an exchange that puts holds on withdrawals (unless it was a hold on withdrawals corresponding only to instant deposit amounts). and KYC can be gotten around in non-fiat facing exchanges, which is all you need, in this case, to reap the advantages of theft.

 

[solex]

DSV is a massive change to Bitcoins economics. It's almost like every-time someone comes up with change to the code, it has unintended consequences.

This is hyperbole. It looks like we are sliding into a new paradigm of paralysis. It used to be "blockchains can't scale" as an argument against increasing the block limit, while focusing only on layer-2. Now its "change to the economics" as an argument against adding extra layer-1 functionality to attract more users, more adoption.
IMHO, DSV has arguably a small economic downside in the blockspace market, but has huge potential upsides for increasing adoption.

As Ryan points out " I actually care about DataSigVerify, it's bad, because it's an artificial subsidy to what should be a very expensive operation."

Ryan is right about many things but not about this. He paints 1MB transactions as an alternative to DSV. Well, those are huge, and a very costly barrier against useful functionality such as trusted oracles. I am not saying that all oracles can be trusted, but there are many situations where it could theoretically work, especially where major companies are signing data. There is a great discussion here which gives a flavour of the pros and cons.

We need to lock the protocol down ASAP. So the world can start building on a stable, economically sound, programable money.

This is lifted straight from CSW's catch-phrase book. Locking the protocol (after removing the block limit) might have made sense when Bitcoin had 95% of the cryptocurrency market. It has been crippled since and now many other coins are competing. Once this bear market ends we can expect BTC's market share to fall back towards its low of ~33%. The error is assuming that because BCH fixes the original problem which crippled BTC, that the clock can be turned back on the market share struggle. The genie is out of the bottle for competing coins. BCH needs functionality like DSV to put it head and shoulders above its competitors.