Gold collapsing. Bitcoin UP.

[brg444]

Which code is open?  You mean Bitcoin code, Not Blockstream's, right?

At this time there is no competition.
It is not likely that there will be any competition soon, if ever.
Adding SPV is really only for Blockstream.

Do you know the complexity of setting up a proof system for which these verifications are made?  Look into it.  It is a major effort taking some of the best minds many years and a LOT of computational power.

 

You are really arguing Blockstream will be the only one building sidechains on top of SPVproof !?

Is there another?

Blockstream has no code per say, they will write some for clients but SPVproof code is open source.

What's to stop Vitalik and the gang or Peter Todd and the crew from creating Blockstream2-3 when they realise that Blockstream business model is viable and is in fact the future of Bitcoin development.

You are underestimating the accomplishment of SNARKs.  It took a very large array of expensive computers, a few years of dedicated time by some of the smartest minds in cryptography, some luck and a lot of dedication and persistence.  A large grant from the EU.  And a very deep, and very specialized mathematics background.

It is pretty a similar set of requirements for starting another Google.  And I think Blockstream may well be the next Google.  If I were Google, I'd have bought them already.

 

They don't have to reinvent SNARKS. Only understanding and implemention implementation is required now.
Surely you are not suggesting the Blockstream crew are the only ones able to do that.

So you concede that there are no others and it is not a lie?
Help me out so that I can be the 2nd then, and make that a lie as you would like to have it.  
Where is the open-sourced SNARKs repository?  I've not had a chance to look for it yet.

Once the SPVproof maths have been properly reviewed and vetted by the community (much like Bitcoin or any other propositions are) then its open source code nature will make it available for anyone to tinker with and come away with their own applications and implementations.

The comparison to Google is somewhat pulled out of nowhere. Sure I imagine their success will be comparable but it is not because of them having built a service that benefits from network effect. They are consultants & developers. They don't have any proprietary product or service to offer except their expertise in the crypto field.

The comparison to Google is apt.  They capitalized on new compression mathematics that they didn't develop, but came out of the human genome project.  Blockstream is also hoping to capitalize on the network effect of Bitcoin, otherwise this would be developed on an altcoin and vetted more properly before plugging it into Bitcoin.

In the lab you can evaluate the code and technology, but not the economics.  At best you can model that, and even the best models fail constantly.
Remember 2008?  Greenspan's models failed.  They all fail ultimately.  The map is not the terrain.

Did you bring SNARKs into the discussion to fit your narrative?

I will repeat : They are consultants & developers. They don't have any proprietary product or service to offer except their expertise in the crypto field. Sure they are piggybacking off Bitcoin's network effect as in it guarantees the long term viability of their business model but they have no network effect proprietary to their service and working for THEM.

Are you so shortsighted that you don't accept the eventuality that IBM, Microsoft, Google, Redhat will find interest in developing their own sidechains or the ones they could be mandated to create by clients.

[1714253259]

1714253259

[1714253259]

1714253259

[1714253259]

1714253259

[Odalv]

So you concede that there are no others and it is not a lie?
Help me out so that I can be the 2nd then, and make that a lie as you would like to have it.  
Where is the open-sourced SNARKs repository?  I've not had a chance to look for it yet.

https://github.com/scipr-lab

[brg444]

Why are we even discussing SNARKs anyway? They are only but a long shot. SPVProof does not require the use of SNARKs.

What is the proof provider that the SPV is verifying?

The work of miners creating the output?

To be quite honest this part is confusing to me but from my understanding SNARKs are an optional method to this whole mechanism?

Maybe I'm wrong?

[Odalv]

Why are we even discussing SNARKs anyway? They are only but a long shot. SPVProof does not require the use of SNARKs.

What is the proof provider that the SPV is verifying?

The work of miners creating the output?

To be quite honest this part is confusing to me but from my understanding SNARKs are an optional method to this whole mechanism?

Maybe I'm wrong?

SNARK proof and SPV proof are not same proofs.

Edit:
Maybe SPV proof can be implemented as SNARK proof ... but I'm not sure .. just idea

[NewLiberty]

Yes we know.  It is the validation of a proof that is EXTERNALLY CREATED.  The Validation and the Proof are coming from the same source, a trusted source until the crypto gets this evaluation.  There are a lot of C operations there, and a lot of math.

I'm comfortable that the core devs that are jumping ship have vetted it to their satisfaction, but then they also have an economic incentive to be satisfied with it as well.

There is not "trusted source" -> it works same as Bitcoin (what chain is longer ? chain with more PoW)
only roles will be changed.  It is not miner who look for then longest sidechain. It is SC-user who must deliver list of HASH-es that proves he destroyed scBTC and now he can unlock BTC.

I think we are getting closer.
Help me to understand what the codebase is, upon which this SPV does its verification.  Is it not the Side Chain?
So perforce Bitcoin must trust each of the side chains' proof mechanisms.
Side Chains may or may not be open source, and the source may or may not get decent analysis with each update.
The complexity risks are interesting in that they enable so many long cons.

[brg444]

Why are we even discussing SNARKs anyway? They are only but a long shot. SPVProof does not require the use of SNARKs.

What is the proof provider that the SPV is verifying?

The work of miners creating the output?

To be quite honest this part is confusing to me but from my understanding SNARKs are an optional method to this whole mechanism?

Maybe I'm wrong?

SNARK proof and SPV proof are not same proofs.

I understand that, which is why I'm not so sure why NL is introducing this "requirement" in the discussion.

[brg444]

OP_SIDECHAINPROOFVERIFY only removes dependence on trusted counterparty. => the core problem that bitcoin seeks to solve

Bingo!

It doesn't actually do this though.  Not yet at least.  The trusted counterparty being the proof provider.
There are precious few folks that can do a good analysis of that counterparty.  The best anyone else can do is trust the evaluation.

Good cryptography takes some time to evaluate, it is complicated.  They should not expect this to be rushed.

:-)  This proof will create user who want exit from SC. Bitcoin miner only verifies this proof. If other user on SC will see it it not valid proof then he can provide valid (with more PoW).

Yes we know.  It is the validation of a proof that is EXTERNALLY CREATED.  The Validation and the Proof are coming from the same source, a trusted source until the crypto gets this evaluation.  There are a lot of C operations there, and a lot of math.

I'm comfortable that the core devs that are jumping ship have vetted it to their satisfaction, but then they also have an economic incentive to be satisfied with it as well.

There is not "trusted source" -> it works same as Bitcoin (what chain is longer ? chain with more PoW)
only roles will be changed.  It is not miner who look for then longest sidechain. It is SC-user who must deliver list of HASH-es that proves he destroyed scBTC and now he can unlock BTC.

thank you, very clear explanation

[NewLiberty]

So you concede that there are no others and it is not a lie?
Help me out so that I can be the 2nd then, and make that a lie as you would like to have it.  
Where is the open-sourced SNARKs repository?  I've not had a chance to look for it yet.

https://github.com/scipr-lab

Thanks for this...
(you may not see me here for a while)

[cypherdoc]

You are dispicible, and I regret ever coming to your defense in previous "troll battles".  If your own privacy is so important, how can you justity putting a bounty on someone else's personal life?  Talk about a double standard.

dude, you really have trouble defining your own ethics don't you? 

Should have let me out you... we could have split the bounty.

[Melbustus]

Do we have a consensus on the unsolved issues in this debate yet?

Correct me if I'm wrong; I've only had time to skim (not read) the last, oh, 150 pages or so (sheesh):

brg444's position:
Sidechains will reduce demand for alt-coins, and increase demand for bitcoins, by allowing alt-coin experimentation that doesn't require a completely new unit.
The economic dynamics are no different than those that would/will arise from implementing Sidechains via a federated model, such as with OT, which does not require any code change to Bitcoin. Thus, there's no more ecosystem risk to adding SIDECHAINPROOFVERIFY to Bitcoin versus doing it on OT anyways.

cypher's position:
The economic incentives surrounding Sidechains may be more complex than they look, especially when merged-mining is taken into account.
The developer incentives/precedent created by allowing a code-change to Bitcoin to get this done may have long run negative consequences, especially since the entity pushing this is for-profit, and comprised of many Bitcoin core-devs.


Fair?

[brg444]

You are dispicible, and I regret ever coming to your defense in previous "troll battles".  If your own privacy is so important, how can you justity putting a bounty on someone else's personal life?  Talk about a double standard.

dude, you really have trouble defining your own ethics don't you? 

Should have let me out you... we could have split the bounty.

 

of course! to no surprise cypher doesn't catch an obvious sarcasm/joke attempt

[cypherdoc]

My argumented has never been that "we should just do it". I have presented a case why it is dangerous for security concerns and integrity of the Bitcoin ledger to concede ALL of the processing of different transactions types to federation/oracles.

So there is a dangerous practice that is not really being done today much at all, but theoretically it could be done, and if it were, it might be dangerous.
And that is why we should just do it?

Do you see why this is unconvincing?

Not being done much today? Are you kidding me?

Coinbase, Counterparty, Coloredcoins, Bistamp.

Every exchanges, any "off-chain" schemes present the exact risk I am referring to. The trend is VERY clear in that sense.

Do you not think that these are security concerns and have a HIGH-risk potential to temper with the Bitcoin ledger?

Is it not true that with proper implementations sidechains are a very tempting alternative to these?

once again, you misunderstand. 

they can mess with their own internal ledgers but any BTC deposited to the general deposit address still lies on the MC.

[Odalv]

Yes we know.  It is the validation of a proof that is EXTERNALLY CREATED.  The Validation and the Proof are coming from the same source, a trusted source until the crypto gets this evaluation.  There are a lot of C operations there, and a lot of math.

I'm comfortable that the core devs that are jumping ship have vetted it to their satisfaction, but then they also have an economic incentive to be satisfied with it as well.

There is not "trusted source" -> it works same as Bitcoin (what chain is longer ? chain with more PoW)
only roles will be changed.  It is not miner who look for then longest sidechain. It is SC-user who must deliver list of HASH-es that proves he destroyed scBTC and now he can unlock BTC.

I think we are getting closer.
Help me to understand what the codebase is, upon which this SPV does its verification.  Is it not the Side Chain?
So perforce Bitcoin must trust each of the side chains' proof mechanisms.
Side Chains may or may not be open source, and the source may or may not get decent analysis with each update.
The complexity risks are interesting in that they enable so many long cons.

SC-client will perform SPV proof

8. Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep
a copy of the block headers of the longest proof-of-work chain

Using SNARKs he can create proof
1. that he "keeps a copy of ALL the block headers of the longest proof-of-work sc-chain" -> user will compress 80 M of sc-headers into few hashes
2. that this sc-chain contains transaction where he destroyed scBTC and this transaction is 2 days old


Edit:
It is not exactly what SC whitepaper say => how to compress SPV
How to compress SPV is detail :-)  we can use SNARKs/SCIP to do verify it has been done.

[brg444]

Do we have a consensus on the unsolved issues in this debate yet?

Correct me if I'm wrong; I've only had time to skim (not read) the last, oh, 150 pages or so (sheesh):

brg444's position:
Sidechains will reduce demand for alt-coins, and increase demand for bitcoins, by allowing alt-coin experimentation that doesn't require a completely new unit.
The economic dynamics are no different than those that would/will arise from implementing Sidechains via a federated model, such as with OT, which does not require any code change to Bitcoin. Thus, there's no more ecosystem risk to adding SIDECHAINPROOFVERIFY to Bitcoin versus doing it on OT anyways.

cypher's position:
The economic incentives surrounding Sidechains may be more complex than they look, especially when merged-mining is taken into account.
The developer incentives/precedent created by allowing a code-change to Bitcoin to get this done may have long run negative consequences, especially since the entity pushing this is for-profit, and comprised of many Bitcoin core-devs.


Fair?

The only valid argument against MM is more potentially more centralization of the miners. One could argue this is an inevitable reality either way.

My position also proposes that the alternative of fulfilling on off-chain or federated servers the demand for any type of transactions that cannot be accomodated on the mainchain can lead to a dangerous loss of incentive for miners.

These schemes effectively deny them the rights to claim all of the network's transaction fees effectively diminishing their incentive to secure.

Sidechains, to that effect, are a valuable alternative that should, imo, be considered a "win" scenario.

[cypherdoc]

Do we have a consensus on the unsolved issues in this debate yet?

Correct me if I'm wrong; I've only had time to skim (not read) the last, oh, 150 pages or so (sheesh):

brg444's position:
Sidechains will reduce demand for alt-coins, and increase demand for bitcoins, by allowing alt-coin experimentation that doesn't require a completely new unit.
The economic dynamics are no different than those that would/will arise from implementing Sidechains via a federated model, such as with OT, which does not require any code change to Bitcoin. Thus, there's no more ecosystem risk to adding SIDECHAINPROOFVERIFY to Bitcoin versus doing it on OT anyways.

cypher's position:
The economic incentives surrounding Sidechains may be more complex than they look, especially when merged-mining is taken into account.
The developer incentives/precedent created by allowing a code-change to Bitcoin to get this done may have long run negative consequences, especially since the entity pushing this is for-profit, and comprised of many Bitcoin core-devs.


Fair?

i've actually refined my argument down to that being the mere introduction of spvp into the source code may break Bitcoin's ability to act as Sound Money.  the spvp should be viewed as an off ramp for BTC to escape to speculative assets of all types on SC's, not only to research utility chains.  once Bitoins sound money function is broken, there will be no incentive to keep BTC on MC.

yes, these offramps and the SC's they lead to will be sold by Blockstream to any willing buyers.

[brg444]

once again, you misunderstand. 

they can mess with their own internal ledgers but any BTC deposited to the general deposit address still lies on the MC.

Except if they decide to run a fractional reserve.

That has nothing to do with my argument anyway which you again so conveniently avoid : TXs are not processed by the miners.

My argument has never been that "we should just do it". I have presented a case why it is dangerous for security concerns and integrity of the Bitcoin ledger to concede ALL of the processing of different transactions types to federation/oracles.

Once again, your brain dead logic fails you.

[cypherdoc]

Does anyone think there is any validity to the suggestion that SPV proofs should be implemented into the Bitcoin protocol simply because a "federated model is not as good for the side chain"?  There are better arguments, this one should not be repeated any more please.

Please understand that I am hoping to help you refine your message here.  Quite a bit of this is really not good at all for the cause you are advocating.

Thanks for distilling the essence of the issues being discussed.

let me distill it even further.

brg444 is trying to scare us into believing that unless we implement spvp to core, all these thousands of SC entities are going to move to federated servers which are opaque and much more ominous and threatening to Bitcoin.  somehow.

that's reality. unless you want to argue there is no demand for transactions types that are not implementable on Bitcoin's mainchain

and i accept that.  i just don't think it represents the existential danger you're trying to make it out to be and certainly is not to be used as a "reason" to implement spvp.

you have used this argument ad nauseam in previous pages. you and buddy Adrian-x have made it a concern to the sound money principle of Bitcoin that the miners incentive to mine the mainchain be lost or tampered with.

you are not being very honest once again cypher

its not a question of honesty, which is one of your favorite ad hominem attacks.  it's our different assessments of the threat of the federated server SC's to Bitcoin.  i don't see any threat at all.  you do.   fine.  others will have to evaluate themselves.

[brg444]

Do we have a consensus on the unsolved issues in this debate yet?

Correct me if I'm wrong; I've only had time to skim (not read) the last, oh, 150 pages or so (sheesh):

brg444's position:
Sidechains will reduce demand for alt-coins, and increase demand for bitcoins, by allowing alt-coin experimentation that doesn't require a completely new unit.
The economic dynamics are no different than those that would/will arise from implementing Sidechains via a federated model, such as with OT, which does not require any code change to Bitcoin. Thus, there's no more ecosystem risk to adding SIDECHAINPROOFVERIFY to Bitcoin versus doing it on OT anyways.

cypher's position:
The economic incentives surrounding Sidechains may be more complex than they look, especially when merged-mining is taken into account.
The developer incentives/precedent created by allowing a code-change to Bitcoin to get this done may have long run negative consequences, especially since the entity pushing this is for-profit, and comprised of many Bitcoin core-devs.


Fair?

i've actually refined my argument down to that being the mere introduction of spvp into the source code may break Bitcoin's ability to act as Sound Money.  the spvp should be viewed as an off ramp for BTC to escape to speculative assets of all types on SC's, not only to research utility chains.  once Bitoins sound money function is broken, there will be no incentive to keep BTC on MC.

yes, these offramps and the SC's they lead to will be sold by Blockstream to any willing buyers.

And you still don't get it....

Federated pegs create the SAME off-ramp using a different proof mechanism. The proof mechanism has no incident on the possibility to create sidechains where BTC can escape to speculative asset.

You should take back what you said and use Melbustus' spoon fed argument for you because yours really makes no sense, once again.

[brg444]

Does anyone think there is any validity to the suggestion that SPV proofs should be implemented into the Bitcoin protocol simply because a "federated model is not as good for the side chain"?  There are better arguments, this one should not be repeated any more please.

Please understand that I am hoping to help you refine your message here.  Quite a bit of this is really not good at all for the cause you are advocating.

Thanks for distilling the essence of the issues being discussed.

let me distill it even further.

brg444 is trying to scare us into believing that unless we implement spvp to core, all these thousands of SC entities are going to move to federated servers which are opaque and much more ominous and threatening to Bitcoin.  somehow.

that's reality. unless you want to argue there is no demand for transactions types that are not implementable on Bitcoin's mainchain

and i accept that.  i just don't think it represents the existential danger you're trying to make it out to be and certainly is not to be used as a "reason" to implement spvp.

you have used this argument ad nauseam in previous pages. you and buddy Adrian-x have made it a concern to the sound money principle of Bitcoin that the miners incentive to mine the mainchain be lost or tampered with.

you are not being very honest once again cypher

its not a question of honesty, which is one of your favorite ad hominem attacks.  it's our different assessments of the threat of the federated server SC's to Bitcoin.  i don't see any threat at all.  you do.   fine.  others will have to evaluate themselves.

I repeat

you have used this argument ad nauseam in previous pages. you and buddy Adrian-x have made it a concern to the sound money principle of Bitcoin that the miners incentive to mine the mainchain be lost or tampered with.

This is exactly what is going to happen with more off-chain/federated servers sidechains.

[cypherdoc]

Do we have a consensus on the unsolved issues in this debate yet?

Correct me if I'm wrong; I've only had time to skim (not read) the last, oh, 150 pages or so (sheesh):

brg444's position:
Sidechains will reduce demand for alt-coins, and increase demand for bitcoins, by allowing alt-coin experimentation that doesn't require a completely new unit.
The economic dynamics are no different than those that would/will arise from implementing Sidechains via a federated model, such as with OT, which does not require any code change to Bitcoin. Thus, there's no more ecosystem risk to adding SIDECHAINPROOFVERIFY to Bitcoin versus doing it on OT anyways.

cypher's position:
The economic incentives surrounding Sidechains may be more complex than they look, especially when merged-mining is taken into account.
The developer incentives/precedent created by allowing a code-change to Bitcoin to get this done may have long run negative consequences, especially since the entity pushing this is for-profit, and comprised of many Bitcoin core-devs.


Fair?

i've actually refined my argument down to that being the mere introduction of spvp into the source code may break Bitcoin's ability to act as Sound Money.  the spvp should be viewed as an off ramp for BTC to escape to speculative assets of all types on SC's, not only to research utility chains.  once Bitoins sound money function is broken, there will be no incentive to keep BTC on MC.

yes, these offramps and the SC's they lead to will be sold by Blockstream to any willing buyers.

And you still don't get it....

Federated pegs create the SAME off-ramp using a different proof mechanism. The proof mechanism has no incident on the possibility to create sidechains where BTC can escape to speculative asset.

You should take back what you said and use Melbustus' spoon fed argument for you because yours really makes no sense, once again.

and you still aren't listening.  who cares about federated servers?  they pose no threat cuz they don't change source code.