Gold collapsing. Bitcoin UP.

[lunar]

To step in to the privacy / anonymity discussion: I recently had an interview with a researcher from Project Titanium, an EU funded science project to track criminals in a multi-cryptocurrency-context. They created a platform to cluster wallets, and it already needs a cluster computing infrastructure, because the graph for Bitcoin has grown to billions of edges. Big Blocks seem to be a good answer on the privacy problem.

@go1111111

On the Privacy/Anonymity discussion. I apologise if you can't stand the guy, hear him out here, as it explains what myself and christoph have i've been getting at.



@3mins "It's a graph problem, right now it's difficult and requires supercomputers, for law enforcement"... It's exponentially harder at scale, GB or TB it becomes "utterly difficult"

So now imagine we have the whole world, petabytes of blockchain data. Once we get past the intersection of Moores law and the exponential difficulty of UXTO analysis, then blockchain privacy is a given.

If only Core hadn't delayed us for 5 years we'd probably be there already.

 

[Norway]

Here's an alternative strategy to scale bitcoin for creative developers:

1. Accept that it might not be possible to parallelize everything.

2. Identify exactly what can't be parallelized. It could be just one process, maybe more.

3. Strip down this process to it's most basic form.

4. Figure out what hardware is best suited for this process. CPU, GPU, maybe someone already made an ASIC for this.

5. Discover the real limit to scaling.

 

[satoshis_sockpuppet]

If you want me to shut up, say so.

No.

But I really wonder why you don't accept the result of PoW voting while you i

Here's an alternative strategy to scale bitcoin for creative developers:

1. Accept that it might not be possible to parallelize everything.

2. Identify exactly what can't be parallelized. It could be just one process, maybe more.

3. Strip down this process to it's most basic form.

4. Figure out what hardware is best suited for this process. CPU, GPU, maybe someone already made an ASIC for this.

5. Discover the real limit to scaling.

The people doing this work are already working in BU and ABC and are the same people whose work you constantly describe as worthless.

CSW and Ayre can bark a lot. But they have shown that they are not capable of doing anything even remotely technically interesting. And worse, they are not able to find people doing this work for them.

The people, who are technically able to do the stuff you describe, are almost all appalled by CSW and his minions.

 

[Norway]

you constantly describe as worthless.

Stop lying @satoshis_sockpuppet

 

[Tom Zander]

Do you agree with this statement?

From your usage of "protocol" to be distinct from "consensus rules", I'd argue that there are more terminology conflicts here.
[doublepost=1543442317][/doublepost]

Here's an alternative strategy to scale bitcoin for creative developers:

1. Accept that it might not be possible to parallelize everything.

2. Identify exactly what can't be parallelized. It could be just one process, maybe more.

3. Strip down this process to it's most basic form.

4. Figure out what hardware is best suited for this process. CPU, GPU, maybe someone already made an ASIC for this.

5. Discover the real limit to scaling.

What makes you think that hasn't happened yet?

I'd be interested to hear what you think is a possible bottleneck for real scaling.

 

[Norway]

@Tom Zander

From your usage of "protocol" to be distinct from "consensus rules", I'd argue that there are more terminology conflicts here.

Yeah, I've used the word protocol myself while talking about consensus rules many times. But I think it makes sense to not use the terms as synonyms. Protocol should describe the format (protocol) nodes use to communicate, and consensus rules should describe the rules the nodes play by.

For instance, in our paper on IBS, we suggest a change to the protocol (a voluntary addition) but not a change to the consensus rules.

What makes you think that hasn't happened yet?

I hope many people are working on this, but I haven't heard about it yet. I think you have done some optimizations in Flowee, but I don't know the details.

I'd be interested to hear what you think is a possible bottleneck for real scaling.

I'm not sure, but I think it could be related to validating a block as a whole unit. I'm not an expert. In IBS, we also open up to incremental validation. You could build different merkle trees simultaniously in an incremental fashion for some (top 3 pools for instance) or all of the nodes you are connected to with IBS.

 

[Tom Zander]

I'm sticking to the industry standard usage of protocol, that avoids most confusion. I hope everyone can do this.

What you may be confusing yourself with is that the "Bitcoin" protocol talks about what you seem to regard as "consensus rules" and this is a distinct topic from the p2p network protocol. Those two protocols are separate and you can write a new communications protocol without having any effect on what makes Bitcoin Bitcoin. As point in fact, adding the graphene concepts are p2p protocol changes. They don't change Bitcoin, though.

There are also payment protocols and many other protocols used in the Bitcoin ecosystem.

> I hope many people are working on this

there are.

 

[Norway]

@Tom Zander
I'm not trying to force anything regarding definitions. If you want to use protocol and consensus rules as synonyms, fine. This is not very important to me. I hope you took a look at IBS.
[doublepost=1543447247][/doublepost]

There are also payment protocols and many other protocols used in the Bitcoin ecosystem.

Yeah, we're working on one.

 

[cypherdoc]

 

[cypherdoc]

 

[cypherdoc]

on SV "locking the protocol". there is no such thing:

 

[cypherdoc]

 

[adamstgbit]

on SV "locking the protocol". there is no such thing:

"Stable" aka a protocol that hardly very changes.
ya sure sounds fine, I just have little faith that locking down the protocal NOW is better then making 5 big key changes and THEN "locking it down"

i think that's the only real distinction between ABC and SV

maybe SV is more aligned with my view, maybe ABC wont be satisfied at making only 5 key changes, maybe they will just HF every 6 months for the next 10years!

which might not be so bad either... really depends on if the change actully means that other devs have to edit and rebuild their own code or just update there node. i can see how you could build an appcation like a poker site the relies on a NODE not your own code. so when theres a HF all you do is update your node in time.

so its all relative and its really hard to say one way is better then the other. we have no choice but to just let this thing play out and see what happens i guess. anyones guess is a wild guess, that much is for sure.

 

[adamstgbit]

I'm sticking to the industry standard usage of protocol, that avoids most confusion. I hope everyone can do this.

What you may be confusing yourself with is that the "Bitcoin" protocol talks about what you seem to regard as "consensus rules" and this is a distinct topic from the p2p network protocol. Those two protocols are separate and you can write a new communications protocol without having any effect on what makes Bitcoin Bitcoin. As point in fact, adding the graphene concepts are p2p protocol changes. They don't change Bitcoin, though.

There are also payment protocols and many other protocols used in the Bitcoin ecosystem.

> I hope many people are working on this

there are.

dosnt matter if its a "protocol change" or "consensus rules" or a "softfork" or a "hardfork"
what matters is the impact these changes have on the poeple that use Bitcoin.

look at what core did. "Segwit is a softfork, if you dont like it dont use it. nothing changes, not even the 1 mb limit."

the Reality of the situation is that its more then likely the application you build ontop of BTC is not going to work, maybe you built your project thinking poeple will always be able to send 20$ via BTC, and the only real choice you have is reworking everything you did to work on LN or go to BCH!
BCH profited from that fact alot!

lets not create a situation where other devs have to either, rewrite code OR move to SV!

 

[bitsko]

permissionless benevolent dictatorship.

voluntary centralization.

 

[cypherdoc]

please be clear. you mean from ABC; that has already played out in the form of rolling 10 block reorg protection and a checkpoint, only recently revealed to be highly coordinated with centralized exchanges. and they're proud of it. no wonder they were so smug so soon.

for anyone who resonated with the concepts in the original Satoshi WP, feel free to come along with SV. there won't be a wholesale gutting of everything Bcore did. for instance, there's no talk about removing libsecp256k1, afaik. the "freezing" you keep hearing about only extends to the basic protocol/concensus rules that will allow businesses to reliably build upon limitlessly for the foreseeable future. development upon those rules is also most certainly welcome.

 

[freetrader]

there's no talk about removing libsecp256k1, afaik

LOL, is this one of SV's selling points right now?

 

[cypherdoc]

Why do you lol? is that your form of condescension?

no it isn't. it's my personal observation as I can think for myself.

 

[freetrader]

Who was talking about removing libsecp256k1?
Or did you just come up with a random thing that SV isn't going to remove?

 

[cypherdoc]

if you were capable of following along you'd understand that a favorite talking point of ABC supporters is that SV is going to revert everything that has been accomplished back down to version 0.1 of the original protocol. no they aren't, and I came up with an example.