Gold collapsing. Bitcoin UP.

[Mengerian]

Did you notice that @Mengerian still has not given an answer if he will support your proposal? He will not. It's a dead end.

I've never been a quick responder on this forum. I get busy with other things, so sometimes I take a while to reply.

Also, when you open the conversation with a series of criticisms and attacks against me, it doesn't exactly predispose me to want to engage in open discussion.

 

[Peter R]

Ledger Journal 2014??

Yes, 2014 is when we started working on it. Greg was involved beginning in 2014. Greg left in September 2015 on the day we publicly announced it at Scaling Bitcoin Montreal.

His reason for leaving wasn't _that_ mysterious though. He quit about 5 minutes after I said on stage that "bitcoin will break down dams erected by special interest groups attempting to block the stream of transactions."

 

[cypherdoc]

right outta the Twilight Zone:

 

[Christoph Bergmann]

I've never been a quick responder on this forum. I get busy with other things, so sometimes I take a while to reply.

Also, when you open the conversation with a series of criticisms and attacks against me, it doesn't exactly predispose me to want to engage in open discussion.

You asked what my problem is, I explained it. I don't think I attacked your person, though.

And you still don't answer the question. Will you support what @satoshis_sockpuppet proposed for the may fork?

 

[cypherdoc]

Yes, 2014 is when we started working on it. Greg was involved beginning in 2014. Greg left in September 2015 on the day we publicly announced it at Scaling Bitcoin Montreal.

His reason for leaving wasn't _that_ mysterious though. He quit about 5 minutes after I said on stage that "bitcoin will break down dams erected by special interest groups attempting to block the stream of transactions."

that was epic. why hide it?

 

[Roy Badami]

not really. OPCHECKMULTISIG was always a thing, altho perhaps much larger data-wise, not to mention perhaps more cumbersome. i've never used multisig so i really don't know.

Sure bare multisig was always possible. But we'd be throwing away the entire infrastructure around multisig (address format, wallet development, etc) and having to start again from scratch. Not to mention bare multisig has a big problem that it is more expensive to send to a multisig address (because the transactions are much bigger) and hence bare multisig addresses (which would themselves have to be huge, BTW) would not necessarily be widely supported by services such as exchanges. This was, IIRC, one of the motivations behind the development of P2SH

what i do know is that p2sh has been abused, imo, to the point that all manner of core dev driven tools/schemes/manipulations have been hidden behind the redeem script. one of my pet peeves.

I'd be interested to see an example of a scenario that you would regard as abuse of P2SH.

 

[cypherdoc]

@Roy Badami

pg 18: https://blockstream.com/sidechains.pdf

also:

https://bitcoincore.org/en/segwit_wallet_dev/#creation-of-p2sh-p2wpkh-address

 

[Zangelbert Bingledack]

Thanks @cypherdoc.

from what i recall ,you were one of the original major proponents of CDSV (or a variant) that allowed onchain betting, to the point that whenever I even hear about the concept, I think of you . what radically changed your mind, other than the possible legality?

The fact that it all actually can be done in script is the main one. No one realized that before. Other than that, the arguments akin to those for RISC over CISC, the possible moral hazard in picking winners and losers (pet use cases favoring specific companies or business plans), and the fact that conditional txs ("smart contracts") need to be built knowing not only what is possible in script but also what the economics are (shifting the economics on existing contracts is problematic; in other words the "set the protocol in stone so companies can build, stop experimenting with the basic instruction set" idea appeals to me).

The legal matter sort of blindsided me when I realized I had not updated on my old assumption that Bitcoin would be constantly hunted by govs; its conspicuous unscatchedness for all these years, and the reasons behind that, indicate that if we keep it in that nearly perfect state we can go much further before clashing with any governments. If we assume the legality ship has sailed already, it's an "in for an inch, in for a mile" dynamic, but here we find Bitcoin well known in the mainstream and no rumblings of any crackdowns. Quite the surprise it seems no one talks about.

 

[sickpig]

@Zangelbert Bingledack

if CDS could be emulated in script (once you lift the number of op_codes per script limit way way over 500), wouldn't the same legality problem applies?

if you didn't do it already I think that read @Peter R's recent reddit post on CDS would be worth.

(CDS it's just an example of any op codes that could be emulated with a longer script using "basic op_codes)

 

[wrstuv31]

"if CDS could be emulated in script (once you lift the number of op_codes per script limit way way over 500), wouldn't the same legality problem applies?"

No. Trading financial instruments that are designed to facilitate money laundering, knowing that is what they are designed for, is different than selling gift cards. Even though gift cards could be used for money laundering.

 

[Mengerian]

The specter of legal ramifications around DSV has been raised.

C'mon ZB, now you're concern trolling?! You're better than that.

 

[go1111111]

@Zangelbert Bingledack, I'm curious about your stance on BSV's threats to 51% any other fork of BCH, and their campaign to keep people from splitting their coins.

You were one of the most eloquent writers about the wonders of market competition between forks, and how this would result in the best coin winning. You were also a huge supporter of user choice. BSV warnings about the dangers of splitting seem like a desperate attempt to keep the battle out of the market and to make it harder for users to choose the fork that they prefer. Any thoughts on that?

 

[kyuupichan]

i've been exploring this but haven't been able to determine if EC also allows specific UTXO control to avoid the marking of certain addresses that have received tracking dust most probably from Chainanalysis. can it do this?

Yes see the Coins tab. Note you only have to be wary of dust received in an address that has been spent from. If it hasn't been spent from it's not an issue. Electron Cash should spend all coins in an address if it spends any; I wrote code to do that.

During the hash war you should ensure which chain(s) the dust lies on. Best to just freeze it and come back to it later.

 

[Zarathustra]

Yes, 2014 is when we started working on it. Greg was involved beginning in 2014. Greg left in September 2015 on the day we publicly announced it at Scaling Bitcoin Montreal.

His reason for leaving wasn't _that_ mysterious though. He quit about 5 minutes after I said on stage that "bitcoin will break down dams erected by special interest groups attempting to block the stream of transactions."

Yes, at the time when @criswilmer 'were really bummed' that Greg left the Ledger Journal, we already knew what he was doing.

 

[AdrianX]

So, seems to be that the Bitcoin SV roadmap involves removing P2SH (because it wasn't in Satoshi's original code). I wonder how many people actually support that? It would destroy the entire ecosystem around multisig, for one thing. (Not to mention his plan to somehow ban burning of coins, and to salvage all burnt coins.)

CSW had a patent application on a better version of multisig.


It's in the wild and working and I'm impressed. I can't break it but then I'm just a user. I was going to ask the developers here if they can break it, I'd like to know if anyone can? As far as I'm concerned it's the future. and I've given my input on P2SH here, Understanding Externalities.

I wouldn't support abandoning P2SH until such time as a free to use option was available to the network, But then again solutions that are not subsidized by the network already exist so I don't see it as important.

To be honest I've been shocked by developers who have said they'd do it all again and split the network just so they can use P2SH. We need to move away from these irrational behaviours and incorporate a more holistic understanding of economics when changing bitcoin code.

 

[Roy Badami]

@Roy Badami

pg 18: https://blockstream.com/sidechains.pdf

That's just multisig, plain and simple .They seem to be using some kind of stealth address scheme to generate the underlying addresses, but the redeemScript itself is just vanilla multisig. I presume it would work just as well with bare multisig.

https://bitcoincore.org/en/segwit_wallet_dev/#creation-of-p2sh-p2wpkh-address

Well, segwit is a whole different ball game, and requires a change to consensus rules. But again, surely the problem is the existence of witness scripts, not the existence of P2SH. Once you allow witness scripts in scriptPubKey, it's natural to allow them in redeemScript too.

P2SH makes the scripting capabilities of bitcoin far more useable. It allows you to have an address secured by an arbitrary script, without us having to invent an address format that can encode arbitrary scripts, and without someone sending to that address having to pay for a potentially very large trainsaction.

It also has the side effect of allowing you to keep the script secret until the first time you spend from the address - which I think is probably beneficial in some cases, but don't feel strongly about.

That's it. That's all P2SH does. It doesn't change the functionality of the bitcoin scripting language at all - with the minor exception of the secrecy issue. It just makes it rather more convenient to use complex scripts in the real world .

EDIT TO ADD: Deprecating P2SH would mean that the vast majority of institutional cold storage schemes would have to be completely redesigned from the ground up to be useable with future BCH (or more likely BSV). How is that going to help adoption?

 

[AdrianX]

i've been exploring this but haven't been able to determine if EC also allows specific UTXO control to avoid the marking of certain addresses that have received tracking dust most probably from Chainanalysis. can it do this?

I don't mark it, I just donate it, or sometimes add it to the fee, the coins on the address which was tagged I believe are as good as tagged. I just leave a note and then consider the fact they are tagged when I use them, I take care not to ever mix output and input of such coins.

 

[freetrader]

CSW had a patent application on a better version of multisig.

Thanks for confirming willingness to break on-chain functionality for the sake of these corporate vested interests.

I now agree with @imaginary_username that this behavior (not yours, but CSW's) is fittingly described as terrorism. Financial terrorism, aided by all manner of legal threats and threat of crashing the market.

The man is a financial terrorist against the existing Bitcoin Cash system, since he does not tolerate the right of others to self-determine the rules of their financial system.

 

[AdrianX]

It seems like you missed, like Ryan, what I wrote on my post: what if I mix my wallet with "new" bitcoins of the BCH network, i.e.: coins mined after the fork?

These coins are not equivalent to the other 17,000,000 coins. They are a liability.

There are 17,000,000 other coins that dont have any liability asosiated with them, treat hasforked coins as a liability not an asset. exchanges and serves providers who don't understand and accommodate for this are going to learn the hard way.

This feature is designed to force miners to converge on a chain tip and not wast resorses splitting the chain. Selling those coins is how miners offset risk, don't take on the miner's risk if the hashwar lasts longer than 17 hrs.
[doublepost=1541796531][/doublepost]

Sure bare multisig was always possible. But we'd be throwing away the entire infrastructure around multisig (address format, wallet development, etc) and having to start again from scratch.

The industry does not seem opposed to even bigger redesignes - see segwit, even signing mesages needed a redesign.

 

[chriswilmer]

Yes, at the time when @criswilmer 'were really bummed' that he left the Ledger Journal, we already knew what he was doing.

It wasn't obvious back then. If it was obvious to you, great.