Gold collapsing. Bitcoin UP.

[Aquent]

Good to have you back @awemany. I just wanted to say in regards to your last sentence:

Yeah. Core is ded. Those guys are a lost cause. They scared to even comment on BU because they have nothing to say! Save for some miner, irrelevant points.

They have created such a group think in their irc spaces it is incredible. They've lost touch completely. And they have behaved in such mindbogglingly stupid ways that I am not even sure anymore their moves are calculated.

I guess it is a mixture really. I probably was right way back when I articulated this idea of gmax's opinion that bitcoin is only possible cus 1mb4eva. Then the group think. Then the double down with their for profit company. So an increase to even 2mb is a threat to them, both economically and ideologically, hence their extreme measures and even their deluded justifications in condoning censorship and even, some of them, actively censoring in bitcoin irc.

Even now, they don't really know whats going on because of stupid tactics like this:

"

• kanzure
  alpalp: not helpful, even if you're correct that they are sockpuppets.
• 2:48 pm
  alpalp
  kanzure: even if not sockpuppets - is there any chance at all anyone with anything at stake will switch to a coin with no development team and hand waving? If so, maybe they deserve to lose their money.
• 2:49 pm
  IMO the goal of the project is just meant to distract useful work
• 2:51 pm
  I dont think a huge number of accounts are sockpuppets, just naive users with small stakes and lots of free time. Voting def seems like socks "

They so out there, they consider everyone they disagree with a sockpuppet (an idea even Adam Back has publicly stated, twice I think or so). A pretty effective method to dismiss ideas if you are stupid enough to consider people like, for example, the wallet developers who all came in favour of increase, as sockpuppets.

Core no longer exists really. It is a was. Can't see for example how Gavin or Jeff can continue working in that environment. Looking back now actually, it is commendable how Gavin has been able to tolerate the many smears of Peter Todd (Grima), and obviously he deserves a mountain of respect for bringing that groupthink to light and launching this much needed catalyst.

I just hope sipa sees the ways. I doubt the maintainer really cares so he'll prob go to whatever. The other, probably smarter ones, can see what's coming so time is ripe for them to jump ship. The rest can stick to their stifling atmosphere and 1mb4eva.

Core is ded. Long live bitcoin!

 

[freetrader]

I invited Adam [...]

He responded that he is willing to discuss in a thread he created on a forum censored by Michael Marquardt, but not willing to participate here.

[...]

Hopefully people can encourage him to change his mind.

That's clearly not going to happen. In that BCT thread he was collecting "defensible" talking points which can be used to attack BU going forward and promoting flex-cap instead as the Core "equivalent" to a consensus-based proposal.

You can see him basically wrapping it up here:

https://bitcointalk.org/index.php?topic=1312371.msg13437179#msg13437179

By not letting go of the misinformed arguments made against BU (e.g. Sybil attack through voting), he is clearly showing that this exercise at BCT was not about an honest review.

 

[Zangelbert Bingledack]

@awemany

Welcome back! Totally agree about evaporative cooling here, and Less Wrong being generally partial-rational (i.e., crazy, too smart for their own good) with a few gems.

I think a special effort to invite decently cogent dissenters and treat them well will be increasingly important. I also think we shouldn't cloister ourselves here and on /r/btc, despite the censorship. Feedback is precious, no matter the circumstances. Even getting censored tells you something about the mindset of people by what they choose to censor hardest. Hence my foray into BCT.

 

[Aquent]

Flexcap is pure poison. I can't comprehend how they can even realistically suggest it.

 

[Justus Ranvier]

I can't comprehend how they can even realistically suggest it.

Which of the following possibilities requires less suspension of disbelief?

1. The proposals suggested by Blockstream Core are made in good faith.
2. The public split between Blockstream and Mike Hearn is theatre - Blockstream is working with R3 to paralyse Bitcoin development and halt the adoption growth it's experienced in the last year to give R3 more time to roll out their own solution.

 

[cypherdoc]

Flexcap is pure poison. I can't comprehend how they can even realistically suggest it.

anything with maaku7 involved, Mr. Freicoin, should be viewed as suspect.
[doublepost=1451843207,1451842535][/doublepost]@Mengerian @Justus Ranvier

as far as the fraud proofs introduced into existing block structure question, these proofs cannot be used by SPV clients (like Mycelium or Breadwallet) if core dev is to be believed. they can only be used to help with the new SW concept of "partially validating nodes".

my sense from looking at SW, is that with SW the fraud proofs can eventually be discarded along with the witness data. this is a big advantage. of course, this is presuming that Bitcoin doesn't have a problem with the whole new idea of "partially validating nodes" that SW is determined to take us to.

 

[Justus Ranvier]

as far as the fraud proofs introduced into existing block structure question, these proofs cannot be used by SPV clients (like Mycelium or Breadwallet) if core dev is to be believed. they can only be used to help with the new SW concept of "partially validating nodes".

I'm not sure what that means.

The way an SPV client should "use" a fraud proof is to validate one that it has received against the block headers and, if the proof is valid, ignore all chains which include the fraudulent block no matter how much proof of work they contain.

SPV clients would not generate fraud proofs themselves - the point of fraud proofs is that validating nodes would produce the proofs for the benefit of SPV clients.

It would be very difficult to implement a fraud proof system that does not help SPV clients. You'd basically have to sabotage the proofs in some way to intentionally prevent them from helping.

 

[cypherdoc]

@Justus Ranvier

specifically this from Pieter:

"This doesn't work for SPV, but it could work for something between a full-node and SPV."

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

 

[Justus Ranvier]

@Justus Ranvier

specifically this from Pieter:

"This doesn't work for SPV, but it could work for something between a full-node and SPV."

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

No idea what he's talking about, unless he's expanding the concept of "fraud proofs" to cover rules that are not fraud, such as a block with "too many" bytes in it.

It is absolutely possible to make fraud proofs for all cases of blocks which contain invalid transactions.

By the way, that's a situation that clearly illustrates why it's a mistake to have "maximum number of bytes in a block" as a consensus rule. It doesn't produce invalid transactions and there's no way to make a compact proof of violation as is possible with all the real consensus rules.

 

[cypherdoc]

@awemany

i find this debate over how to "prune" data to be fascinating; specifically the difference in proposed solutions btwn 1. UTXO commitments and 2. SW.

the former accomplished by pruning entire chunks of block history, yours being everything up to the last years worth of blocks while maintaining UTXO set and miner integrity thru commitments while the latter being accomplished by maintaining all of the block history while pruning 90-99% of the UTXO set and all of the witness data via allowing a new form of "partial validating node" with security enforced by fraud proofs as outlined by Pieter via SW.

which is more efficient? Pieter and theymos claim the latter.
[doublepost=1451845894][/doublepost]@Justus Ranvier

i agree. he needs to explain why it's not possible to provide fraud proofs for SPV clients like Mycelium or Breadwallet.
[doublepost=1451846359][/doublepost]not bad-der

 

[tynwald]

I would argue Back basically started it by putting the concern troll bait out there.
<snip>
Tremendous tremendous systemic risks and moral hazard in this Core clique delusion that they have any such thing as peer review or any proposal process whatsoever.

This is a key risk of development tending towards group-think as "outsiders" are excluded over time. RBF, as proposed by Todd, and preference for soft-forks would both have been solid grounds for developers to be sacked in Banking IT where I have worked for 15+ years.

Simply idiotic proposals which would have been laughed out of contention, followed by pink slips for all promoting such anti-user, reckless experimentation on a network valued in billions.

 

[Bagatell]

@tynwald Burn the Banker!

 

[Justus Ranvier]

Simply idiotic proposals which would have been laughed out of contention, followed by pink slips for all promoting such anti-user, reckless experimentation on a network valued in billions.

That kind of behavior is grounds for a pink slip in Bitcoin too, it's just that decentralized HR departments work more slowly.

 

[cypherdoc]

No idea what he's talking about, unless he's expanding the concept of "fraud proofs" to cover rules that are not fraud, such as a block with "too many" bytes in it.

It is absolutely possible to make fraud proofs for all cases of blocks which contain invalid transactions.

By the way, that's a situation that clearly illustrates why it's a mistake to have "maximum number of bytes in a block" as a consensus rule. It doesn't produce invalid transactions and there's no way to make a compact proof of violation as is possible with all the real consensus rules.

he states that his purpose is to design fraud proofs for the 2 consensus rules that can't be enforced in a pruned data set currently: 1. miners creating more fraudulent fees for themselves in blocks and 2. miners spending from a UTXO that never existed.

his fraud proof solutions for those incl 1. add input amounts of each txout to the witness set and 2. add both the blockheight and Merkle chain to the txout in the witness set.

the nice thing about SW is that these fraud proofs can then be deleted along with their signatures freeing up space for base data.

 

[Zarathustra]

Adam's thread (with Maxwell as the lead moderator) got censured.
Peak insanity imminent?

 

[Justus Ranvier]

he states that his purpose is to design fraud proofs for the 2 consensus rules that can't be enforced in a pruned data set currently: 1. miners creating more fraudulent fees for themselves in blocks and 2. miners spending from a UTXO that never existed.

If they want pruned nodes to be able to generate all fraud proofs before implementing anything at all, then they are putting the cart before the horse.

Handling that case is extremely sensitive, and it's going to take a long time to make sure that any solution to that problem is valid, with no overlooked vulnerabilities which could compromise the ledger.

It makes more sense to implement the proofs that can be generated by non-pruned nodes first to plug the massive security vulnerability that exists now, and then work on a long term plan for pruned node security.

 

[cypherdoc]

@Justus Ranvier

If they want pruned nodes to be able to generate all fraud proofs before implementing anything at all, then they are putting the cart before the horse.

as you said previously, the only nodes generating fraud proofs will be the full nodes in SW. partially validating/pruned nodes will simply relay them.

i agree that such a radical change to the protocol needs long term testing esp the ANYONE_CAN_SPEND part of txs.

i'm not advocating SW as a primary step. it is much simpler and less complex to inc blocksize. i like BU as a first step but i still wonder about it's ability to track/communicate/recognize other implementations that might start generating a longer chain which then could cause a fork. maybe @theZerg can comment more on this.

my goal this weekend was to understand SW as deeply as i can so as to understand where the other side is coming from.

 

[Zangelbert Bingledack]

All my posts are still there in Adam's thread.

 

[Justus Ranvier]

my goal this weekend was to understand SW as deeply as i can so as to understand where the other side is coming from.

SW is a solution for transaction malleability.

Solving malleability is essential for Lightning Network, but just "nice to have" for Bitcoin transactions.

I wouldn't expect Blockstream to have put much more than a cursory effort into using SW for fraud proofs, because their primary concern is LN.

 

[tynwald]

@tynwald Burn the Banker!

sure, but spare the geeks ...