Gold collapsing. Bitcoin UP.

[Zarathustra]

The 'misery index' delivered a rare buy signal for the segregated version of Bitcoin, because so many hodlers are sad and miserable.

https://www.cnbc.com/2018/03/09/wall-street-analyst-creates-new-index-that-says-when-to-buy-bitcoin.html

 

[Tom Zander]

It's pretty easy to fuck up the one thing that makes your product so valuable, being good money.

In context, this is about adding new products that competition already has. I find it difficult to agree that in that specific case it is easy. Please elaborate how you see adding something, without changing your core product, can destroy your core product with ease. You must have some business experience to share if you come to such a strong position.

Bitcoin Cash is the conservative plan for a worldwide currency. It shouldn't become a testbed for half-baked "solutions" and fancy tech stuff out of fear of the competition.

Which solutions are those "half baked" ones you talk about?

And what are your personal benchmarks for when a solution is no longer "half baked" but good enough?

Also my question to @awemany included a relevant question; what does 6 months extra buy you? Or in other words: what exactly are you looking for that has to be done that hasn't been done in the past 6 months of work?

 

[rocks]

I always thought in 2012-13 most core devs were on board with the scaling plan, at least that is how Pieter, Wladimir and others positioned themselves. According to this post Greg was already arguing with Satoshi for full blocks in 2009. If that is the case Gavin should have never have granted him git access and have kept control limited to those who clearly were on board with the original plan, himself and Hearn.

https://www.reddit.com/r/btc/comments/83unxd/satoshi_vs_greg_max_on_bitcoin_scaling_one_of/?st=jeognn2w&sh=ee48b9dd

BTW, here is the thread in 2013 for reference when Todd first started to float the idea of keeping the cap, and this is Hearn's immediate response essentially saying that if you want to do that to fork off an make your own altcoin. Which is what BTC is, a fork away from the original vision. Notice how Hearn refers to Gavin as being the decision maker too.

https://bitcointalk.org/index.php?topic=144895.msg1537223#msg1537223

 

[throwaway]

Will there be a new Bitcoin Unlimited compatible with BitPay invoices? The current 1.2.0.1 just tells me that the server response was "Forbidden".

@theZerg

----------

As an aside, that BitPay fails an otherwise-correct transaction just because you transmitted before they gave you the go-ahead is moronic.

----------

@rocks I don't think gmaxwell was talking to Satoshi there, and that message is definitely not from 2009 (it talks about things happening "for years").

 

[AdrianX]

Once you're using BCH and all your friends are too, its a pain to switch everyone over.

;-) have you tried Shapeshift.io? It's not hard at all. When integrated into a wallet like coinome you don't even think about it. But I'm not saying that disproves your point. We still need to build an appropriate foundation. I just don't think the pain to switch everyone over from one digital asset to another is the motivating reason. It's keeping people in your network that is important and its building appropriate use cases that are important.

 

[Tomothy]

So, has anybody talked with miners about how much time they need to prep before any hard fork upgrades? My understanding is the goal was to have a hard fork in May with some new (old) opcodes and changing the daa. Is it known what's yet agreed upon with regards to which opcodes are confirmed? Further what about if/what changes are coming to the DAA? additionally, is this code that would be hard forked to but not activate until 90 days after May or something or what? Just wondering since it's unclear what's being changed, how changes were coordinated outside of the developers and timelines on all of this stuff.

Assuming stuff is changing, is there miner buy in to what's been proposed? Some of the discussion like Oracles in my mind, sound great, but if miners are risk averse and not in favor of those changes it can be a lot of ado about nothing. Sorry just trying to get a better understanding of what to expect to happen or not happen over the next six months to a year.

I guess what I'm asking is are expectations properly being set and managed by both the community, miners, developers, and business stakeholders. A sub-optimal outcome in may would be code released for a hardfork and no miners run it because they havent been provided or rather don't feel like they've been given enough time to evaluate the proposed changes and there is insufficient objective evidence of the proposed changes having been run through rigorous testing. Testing here is critical based on the money involved. If bch miners are going to lose money, they'll just go back to btccore.

 

[AdrianX]

This insurance must trust Rainman who holds keys to describe the weather. Rainman is the oracle, and he tells the system if it was rain or not.

So, it's a centralized service. Rainman doesn't need blockchain scripting to provide his service. He might as well run a website where he sells insurance/derivatives for BCH.

In Africa, you pay a kid with a $0.10 candy to go pore water into the rain gauge - profit, the solutions to high tech problems are very low tech.

 

[rocks]

Assuming stuff is changing, is there miner buy in to what's been proposed? Some of the discussion like Oracles in my mind, sound great, but if miners are risk averse and not in favor of those changes it can be a lot of ado about nothing. Sorry just trying to get a better understanding of what to expect to happen or not happen over the next six months to a year.

I guess what I'm asking is are expectations properly being set and managed by both the community, miners, developers, and business stakeholders. A sub-optimal outcome in may would be code released for a hardfork and no miners run it because they havent been provided or rather don't feel like they've been given enough time to evaluate the proposed changes and there is insufficient objective evidence of the proposed changes having been run through rigorous testing. Testing here is critical based on the money involved. If bch miners are going to lose money, they'll just go back to btccore.

The same problem existed in Aug 2017. The answer last year was to make the UAHF chain require the change in consensus rules to be in the first block. For last Aug that meant the first block after the activation height had to contain 2MB in order to be a valid block.

This is important because it forces the entire network to upgrade to the new consensus rules. If a miner or other user does not agree, they separate from the network.

The upcoming May UAHF should follow the exact same precedent. It should require the new op codes to be used in the first block after the activation height. Either you participate or you are separated.

 

[Zangelbert Bingledack]

@witly I agree that general insurance and many other applications will require dedicated (paid) oracles. For insurance, it serves as a beneficial unbundling of the role of fact-checking from the role of insuring.

Since I'm eager to take advantage of new use cases on a faster timescale than the professionalization of a whole new dedicated-oracle industry would allow, the point of the example I gave about the subsistence farmer was to suggest low-hanging fruit that could be possible almost immediately, using existing infrastructure.

@reina Yes, like Byteball but of course not a DAG. They seem to have a good handle on some potential realistic use cases.

 

[Richy_T]

We already kind-of solved the hard-fork methodology with BU. Miners just start accepting the new rules and signal that they are doing so. When a miner feels that a block they mine using the new rules is unlikely to be orphaned, they mine such a block. I think this is a paradigm we should stick to going forward.

The forcing of the first block having to cause the fork with cash was the direct result of not wanting the Segwit abomination (which could not even muster 40% of signalling) attached and was necessary and unavoidable but a bit unfortunate IMO.

I feel like if we are not careful, we will have left Core behind but it will be a case of "Meet the new boss, same as the old boss."
[doublepost=1520957415,1520956787][/doublepost]Hmm. Just a thought. Instead of signalling, is there a way that miners could mine speculative blocks that would incorporate the new rules but at much lower/no difficulty such that they could see if they were likely to be accepted by other miners? Could this be tied in to weak blocks somehow? @Peter R

 

[Peter R]

@Richy_T: Interesting idea!

One limitation of current miner signalling schemes like BIP009 is that the signalling is cheap. It doesn't directly cost a miner anything to signal that he's ready to support a new feature (e.g., OP_GROUP) when really he's not.

Following with the OP_GROUP example, once a miner was reasonably sure that OP_GROUP was supported by a sufficient majority, he could dedicate a small portion of his hash power to attempt to mine a "test block" with an OP_GROUP transaction in it. Chances are good that the first such block he mined would be a weak block, allowing the entire network to then watch whether or not other weak blocks were added above his test block.

If the next few weak blocks were added above the test block, then that's evidence that miners are indeed accepting the OP_GROUP transactions. The upgrade is complete.

If instead the next few weak blocks fork around the test block, then that's evidence that there is insufficient hash power support at the moment. The upgrade is not complete.

The reason this is helpful is because, should the test block be orphaned, chances are the orphaning event didn't actually result in a finanical loss to the miner (as weak blocks pay no block reward). But the event is observable and the miner can switch back to the old pre-OP_GROUP rules quickly before he finds a strong block (that would result in a financial loss to him).

 

[hodl]

But they are not the only reasons that people support liberty. There is a segment of the population of self-described libertarians—described here as brutalists—who find all the above rather boring, broad, and excessively humanitarian. To them, what’s impressive about liberty is that it allows people to assert their individual preferences, to form homogeneous tribes, to work out their biases in action, to ostracize people based on “politically incorrect” standards, to hate to their heart’s content so long as no violence is used as a means, to shout down people based on their demographics or political opinions, to be openly racist and sexist, to exclude and isolate and be generally malcontented with modernity, and to reject civil standards of values and etiquette in favor of antisocial norms.

https://fee.org/articles/against-libertarian-brutalism/?utm_content=68524117&utm_medium=social&utm_source=facebook

 

[Tom Zander]

once a miner was reasonably sure that OP_GROUP was supported by a sufficient majority, he could dedicate a small portion of his hash power to attempt to mine a "test block" with an OP_GROUP transaction in it. Chances are good that the first such block he mined would be a weak block,

This may then be a good time to talk about Weak Blocks, as they keep coming up.

I think this is one of the first well described emails for weak blocks; https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011157.html

One effect is that miners change behaviour in a subtle way. Many will no longer create their own block-template based on their own mempool. Instead, they will use the weak block that they receive from a competing miner.

The question that I'd like to raise here is if people considered how that affects censorship-resistance. I think weak blocks will be horrible for censorship resistance.

So, the mining network is censorship resistant currently because each miner designs his own block. Thus if a group of miners decides to no longer mine satoshi-dice transactions, they are free to censor that way but other miners will eventually mine those blocks anyway becaues they mine from their own mempool.

Then if we go to the situation where in the vast majority of cases a miner needs to just build on top of a weak block, they can stop running their own mempool (just mine an empty block until the first weak block comes in) Which saves cost. But kills censorship resistance.

Thoughts?

 

[79b79aa8]

but some arbitrary miner will still have to mine those weak blocks, what makes you assume the censorship-motivated miners would be the ones doing it? i don't see why there would be a larger proportion of censorship-prone miners that would be willing to include txns in a block.

 

[albin]

@Tom Zander

I'm unclear, in the scenario that you describe, why the censoring miner is always creating the weak block, instead of the opposite also happening?

 

[rocks]

We already kind-of solved the hard-fork methodology with BU. Miners just start accepting the new rules and signal that they are doing so. When a miner feels that a block they mine using the new rules is unlikely to be orphaned, they mine such a block. I think this is a paradigm we should stick to going forward.

And what happens when not enough miners signal for the rule changes? We have already seen how that plays out in the block size debate.

I guess it really comes down to if you see the miners in control or users in control. I am still of the view that Satoshi's WP gave miners control over transaction ordering within a given set of consensus rules, but end users have final say in what the consensus rules are.

This is how the May UAHF happened, the BTC chain is still the longest chain by POW. We are only on the BCH chain because we as end users reject chains that do not have a 2MB block on Aug 1st. That is literally the rule (we set not miners) for why we are on the BCH chain.

 

[Tom Zander]

but some arbitrary miner will still have to mine those weak blocks, what makes you assume the censorship-motivated miners would be the ones doing it? i don't see why there would be a larger proportion of censorship-prone miners that would be willing to include txns in a block.

You missed the part where its miners that don't have to create the block spend less ? Both Gavins email and my post repeated that point.

 

[79b79aa8]

yes, and wanting to spend less applies equally to all miners -- those who would censor and those who would not.

in the end, someone has to organize txns in a block, and everyone wants to make as much profit as possible. it is not clear how we go from that to a presumption that it will be the censoring-prone miners that take the hit. is it because they are incentivized by their censoring ideology, to the point of being willing to put a dent on their margin?

 

[hodl]

According to this post Greg was already arguing with Satoshi for full blocks in 2009.

that quote from Greg was not posted in 2009. probably sometime in 2016-17.

 

[Tom Zander]

is it because they are incentivized by their censoring ideology, to the point of being willing to put a dent on their margin?

What dent in their margin?

And, yes, in case you haven't noticed, (in which case lucky you), in todays world there are a lot of paying customers if you have that control. If you can censor a wikileaks getting paid, as a silly example.