Gold collapsing. Bitcoin UP.

[sickpig]

In this scheme, there will be only BTC buying with the fiat at exchanges.  No BTC is sold to the market.  Only scBTC is sold to the market but people believe the notion of the peg so they pay the same for them as they would for BTC (because after all they can be redeemed for BTC with only a 100 block delay in spend-ability).

Endgame is there are a lot of the scBTC created, reducing BTC liquidity and pumping the BTC fiat price... until it unwinds.

There is no peg.
There is no spoon.

Here is what I believe to be the flaw in your scenario :

If, as you say, people believe in the peg (which they absolutely should) then they will not buy your scBTC. In reality, the market has no incentive to purchase your scBTC over BTC if they are the same price.  

The reason for this? Well you have suggested it yourself : the "block delay in spend-ability". What makes the best money? The most cost effective and versatile exchangeable asset. BTC is more easily exchangeable with fiat (because of liquidity) and other scBTCs than scBTC is and is also more cost-effective at doing so. No matter the 1:1 fiat peg, BTC is a more desirable unit than scBTC. BTC has better fungibility and liquidity in the economy than scBTC.

Here is where you are flatly wrong.  There clearly is an incentive, the time incentive.
To change BTC to scBTC, you will have to wait for 100 blocks or so, whatever the confirmation time may be.
If you buy them at exchange, there is no wait.

This confirmation exchange value is created in both ways in the transaction.  People will pay a premium for time, localbitcoin pricing is evidence enough of this.

Maybe I'm wrong but don't the atomic swaps described in the paper remove "the time incentive"?
Am I missing something obvious?

Atomic swaps don't remove it, but they are a different sort of exchange entirely.  They are a sort of middle ground, in between in terms of time and autonomy.  
They are p2p and negotiated (rather than something I can do on my own via exchange or SPV)
They also have a time requirement, just not as long.  
They could be somewhat automated with a hosted order book, so they may end up being closer to the exchange model, which would give them a bit of a premium over the SPV method.
The SPV folks (presumably the slowest of these three, each are more or less unused) pay in time and save in money.

Thanks for the explanation.

Now setting aside time consideration do you confirm that is possible exchanging BTC and scBTC through atomic swaps?
(I'm asking b/c notme says is not possible)

edit: slightly clarify the question.

[1713876817]

1713876817

[1713876817]

1713876817

[1713876817]

1713876817

[1713876817]

1713876817

[NewLiberty]

In this scheme, there will be only BTC buying with the fiat at exchanges.  No BTC is sold to the market.  Only scBTC is sold to the market but people believe the notion of the peg so they pay the same for them as they would for BTC (because after all they can be redeemed for BTC with only a 100 block delay in spend-ability).

Endgame is there are a lot of the scBTC created, reducing BTC liquidity and pumping the BTC fiat price... until it unwinds.

There is no peg.
There is no spoon.

Here is what I believe to be the flaw in your scenario :

If, as you say, people believe in the peg (which they absolutely should) then they will not buy your scBTC. In reality, the market has no incentive to purchase your scBTC over BTC if they are the same price.  

The reason for this? Well you have suggested it yourself : the "block delay in spend-ability". What makes the best money? The most cost effective and versatile exchangeable asset. BTC is more easily exchangeable with fiat (because of liquidity) and other scBTCs than scBTC is and is also more cost-effective at doing so. No matter the 1:1 fiat peg, BTC is a more desirable unit than scBTC. BTC has better fungibility and liquidity in the economy than scBTC.

Here is where you are flatly wrong.  There clearly is an incentive, the time incentive.
To change BTC to scBTC, you will have to wait for 100 blocks or so, whatever the confirmation time may be.
If you buy them at exchange, there is no wait.

This confirmation exchange value is created in both ways in the transaction.  People will pay a premium for time, localbitcoin pricing is evidence enough of this.

Maybe I'm wrong but don't the atomic swaps described in the paper remove "the time incentive"?
Am I missing something obvious?

Atomic swaps don't remove it, but they are a different sort of exchange entirely.  They are a sort of middle ground, in between in terms of time and autonomy.  
They are p2p and negotiated (rather than something I can do on my own via exchange or SPV)
They also have a time requirement, just not as long.  
They could be somewhat automated with a hosted order book, so they may end up being closer to the exchange model, which would give them a bit of a premium over the SPV method.
The SPV folks (presumably the slowest of these three, each are more or less unused) pay in time and save in money.

Thanks for the explanation.

Now setting aside time consideration do you confirm that is possible exchanging BTC and scBTC through atomic swaps?
(I'm asking b/c notme says is not possible)

edit: slightly clarify the question.

Side chains may certainly differ from each other, but I don't see any reason that it would not be possible to atomic swap so long as they support the script functions like OP_DUP,  OP_HASH160, hash, OP_EQUALVERIFY, OP_CHECKSIG, SIGHASH_ALL.

I'm curious what limitation notme considered.  Maybe just that there is not much reason to atomic swap since an SPV is pretty much the same thing but without the phase one negotiations.  Since these are already set.
The main difference is that an atomic swap doesn't change the amount of currency in the chain, just changes the ownerships.

Edit:  Appendix C of http://www.blockstream.com/sidechains.pdf makes it pretty clear that this is a thing.

[sickpig]

Now setting aside time consideration do you confirm that is possible exchanging BTC and scBTC through atomic swaps?
(I'm asking b/c notme says is not possible)

edit: slightly clarify the question.

Side chains may certainly differ from each other, but I don't see any reason that it would not be possible to atomic swap so long as they support the script functions like OP_DUP,  OP_HASH160, hash, OP_EQUALVERIFY, OP_CHECKSIG, SIGHASH_ALL.

good, thanks.

After re-reading Appendix C and other comments from this and other threads, it seems to me that atomic swaps could be executed almost "instantaneously" (1). But maybe I'm wrong. 

(1) if we're considering exchanging BTC with scBTC through atomic swap, the exchange process duration should be a function of the confirmation time in btc blockchain, the sidechain's ledger
     confirmation time and locktime used in the txs involved in the swap.

I'm curious what limitation notme considered.  Maybe just that there is not much reason to atomic swap since an SPV is pretty much the same thing but without the phase one negotiations.  Since these are already set.
The main difference is that an atomic swap doesn't change the amount of currency in the chain, just changes the ownerships.

Edit:  Appendix C of http://www.blockstream.com/sidechains.pdf makes it pretty clear that this is a thing.

just as reference this what "notme" said about atomic swaps:

Atomic swaps don't involve BTC, they involve scBTC and an altcoin that also exists on the sidechain along with the scBTC.

[notme]

Sorry for the confusion, I was thinking of atomic swaps within one chain, but rereading appendix C I see there is another cross chain method that is using that terminology.  So, yes you can move coins across chains and avoid the SPV proof if you can find a willing partner to perform the trade with.  Unfortunately, the sidechains paper is light on details, so I'm not sure if this can be done without protocol changes to BTC.

[thezerg]

I think other corde devs can keep core devs in Blockstream in check.  And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.  Frankly, if you have a problem with it, then shut up and put up.  Put up BTC (and/or encourage others to do so) to fund a core dev.  You don't need permission.  Just start paying a great developer and he'll become a core dev once he proves his worth.

And there's another thing that I like about sidechains.  Lately, I hear about cool technologies... for example maidsafe distributed storage, and the zen-something public supercomputer... and get excited.  And then I hear about their stupid pump and dump alt-coin that you have to use and its a pretty big letdown.  Sidechains would give no excuses to create these app-specific coins -- or what I mean is that an honest company would create a Sidechain with pegged currency to take advantage of blockchain technology but avoid accusations and temptations to pump and dump.  And also, a Sidechain will avoid the likely SEC inquiry as issuing the coin before it has any use whatsoever (before your product is done) starts to make it look a lot like a security.

[cypherdoc]

i hate articles like these, esp from guys like J Levin who i think is generally respected in the community b/c of his Oxford CS training and Coinometrics.  i however have not been impressed with his previous thinking as he is one of the geeks who doesn't fully get Bitcoin:

https://medium.com/@jony_levin/i-love-the-blockchain-just-not-bitcoin-354c511ad3e5

same reason, same hate from me:  he implies that the Bitcoin currency unit can be changed or that it can somehow be replaced or added to with another token (currency unit).  he then doesn't even mention how tx fees can make up for lost blockchain security incentives after a block halving which is a disingenuous and incomplete discussion.  a mention that tx fees "need and can" increase to compensate for decreasing block reward would have been totally appropriate and complete.

this is still a problem i have with making protocol changes; how do you insert a protocol change that doesn't favor a certain group of ppl or disadvantage the ppl that have come before the change?  b/c Bitcoin is an open community, outside voices are allowed to be heard loud and clear.  however, we never know to what extent they are personally invested in the former rule set (protocol) as opposed to the new rule set they are proposing.

[sickpig]

Sorry for the confusion, I was thinking of atomic swaps within one chain, but rereading appendix C I see there is another cross chain method that is using that terminology.  So, yes you can move coins across chains and avoid the SPV proof if you can find a willing partner to perform the trade with.  Unfortunately, the sidechains paper is light on details, so I'm not sure if this can be done without protocol changes to BTC.

ok. thanks for the clarification.

The paper reference a more detailed description of atomic swaps here:

https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949

[justusranvier]

And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.

TBF and Blockstream are the only companies paying people to develop on Bitcoin Core.

Bitcoin Core is not the only implementation of Bitcoin.

Conformal Systems did, in fact, "put up" and received little-to-no acknowledgement for doing so. (To say nothing of all the other developers who tried to do the same thing but were not able to overcome the resistance and stonewalling via which Bitcoin Core team defends their turf)

"Shut up or put up" is a lie, because as soon as somebody actually does it the goal posts promptly move.

[cypherdoc]

I think other corde devs can keep core devs in Blockstream in check.  And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.  Frankly, if you have a problem with it, then shut up and put up.  Put up BTC (and/or encourage others to do so) to fund a core dev.  You don't need permission.  Just start paying a great developer and he'll become a core dev once he proves his worth.

And there's another thing that I like about sidechains.  Lately, I hear about cool technologies... for example maidsafe distributed storage, and the zen-something public supercomputer... and get excited.  And then I hear about their stupid pump and dump alt-coin that you have to use and its a pretty big letdown.  

look at the JLevin article i just put up.  he's moving in the opposite direction as you, it appears, in regards to "tokens".

Sidechains would give no excuses to create these app-specific coins -- or what I mean is that an honest company would create a Sidechain with pegged currency to take advantage of blockchain technology but avoid accusations and temptations to pump and dump.  And also, a Sidechain will avoid the likely SEC inquiry as issuing the coin before it has any use whatsoever (before your product is done) starts to make it look a lot like a security.

so what's the financial incentive for a company to create a SC with 2wp w/o a token?

[notme]

Sorry for the confusion, I was thinking of atomic swaps within one chain, but rereading appendix C I see there is another cross chain method that is using that terminology.  So, yes you can move coins across chains and avoid the SPV proof if you can find a willing partner to perform the trade with.  Unfortunately, the sidechains paper is light on details, so I'm not sure if this can be done without protocol changes to BTC.

ok. thanks for the clarification.

The paper reference a more detailed description of atomic swaps here:

https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949

Unfortunately that doesn't address my question, which is specifically: how do we check if the random number chosen by A is known?  Verifying signatures is obviously supported, but how do you go about first requiring a number be known without already knowing it (hash it I'd guess), and then what OP code do you use to verify it?

[notme]

I think other corde devs can keep core devs in Blockstream in check.  And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.  Frankly, if you have a problem with it, then shut up and put up.  Put up BTC (and/or encourage others to do so) to fund a core dev.  You don't need permission.  Just start paying a great developer and he'll become a core dev once he proves his worth.

And there's another thing that I like about sidechains.  Lately, I hear about cool technologies... for example maidsafe distributed storage, and the zen-something public supercomputer... and get excited.  And then I hear about their stupid pump and dump alt-coin that you have to use and its a pretty big letdown.  

look at the JLevin article i just put up.  he's moving in the opposite direction as you, it appears, in regards to "tokens".

Sidechains would give no excuses to create these app-specific coins -- or what I mean is that an honest company would create a Sidechain with pegged currency to take advantage of blockchain technology but avoid accusations and temptations to pump and dump.  And also, a Sidechain will avoid the likely SEC inquiry as issuing the coin before it has any use whatsoever (before your product is done) starts to make it look a lot like a security.

so what's the financial incentive for a company to create a SC with 2wp w/o a token?

How about to provide a service via that sidechain that is paid for in BTC pegged currency?  I'd much rather innovate to earn BTC than innovate and then have to worry about bootstrapping a currency.

[Adrian-x]

I think other corde devs can keep core devs in Blockstream in check.  And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.  Frankly, if you have a problem with it, then shut up and put up.  Put up BTC (and/or encourage others to do so) to fund a core dev.  You don't need permission.  Just start paying a great developer and he'll become a core dev once he proves his worth.

And there's another thing that I like about sidechains.  Lately, I hear about cool technologies... for example maidsafe distributed storage, and the zen-something public supercomputer... and get excited.  And then I hear about their stupid pump and dump alt-coin that you have to use and its a pretty big letdown.  Sidechains would give no excuses to create these app-specific coins -- or what I mean is that an honest company would create a Sidechain with pegged currency to take advantage of blockchain technology but avoid accusations and temptations to pump and dump.  And also, a Sidechain will avoid the likely SEC inquiry as issuing the coin before it has any use whatsoever (before your product is done) starts to make it look a lot like a security.

With the protocol as is it's possible to design these technologies around Bitcoin, the pump and dump is market hype, IPO style.
Innovators still need a profit motive and to mitigate risk SC don't provided that. I still haven't been convinced we need the Blockstreem protocol to enable this innovation, why not use what we have.

[cypherdoc]

I think other corde devs can keep core devs in Blockstream in check.  And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.  Frankly, if you have a problem with it, then shut up and put up.  Put up BTC (and/or encourage others to do so) to fund a core dev.  You don't need permission.  Just start paying a great developer and he'll become a core dev once he proves his worth.

And there's another thing that I like about sidechains.  Lately, I hear about cool technologies... for example maidsafe distributed storage, and the zen-something public supercomputer... and get excited.  And then I hear about their stupid pump and dump alt-coin that you have to use and its a pretty big letdown.  

look at the JLevin article i just put up.  he's moving in the opposite direction as you, it appears, in regards to "tokens".

Sidechains would give no excuses to create these app-specific coins -- or what I mean is that an honest company would create a Sidechain with pegged currency to take advantage of blockchain technology but avoid accusations and temptations to pump and dump.  And also, a Sidechain will avoid the likely SEC inquiry as issuing the coin before it has any use whatsoever (before your product is done) starts to make it look a lot like a security.

so what's the financial incentive for a company to create a SC with 2wp w/o a token?

How about to provide a service via that sidechain that is paid for in BTC pegged currency?  I'd much rather innovate to earn BTC than innovate and then have to worry about bootstrapping a currency.

agreed, but what would be the mechanism of the pmt?  is this what "demurrage" is supposed to do ala LukeJr keeps talking about?

[sickpig]

Sorry for the confusion, I was thinking of atomic swaps within one chain, but rereading appendix C I see there is another cross chain method that is using that terminology.  So, yes you can move coins across chains and avoid the SPV proof if you can find a willing partner to perform the trade with.  Unfortunately, the sidechains paper is light on details, so I'm not sure if this can be done without protocol changes to BTC.

ok. thanks for the clarification.

The paper reference a more detailed description of atomic swaps here:

https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949

Unfortunately that doesn't address my question, which is specifically: how do we check if the random number chosen by A is known?  Verifying signatures is obviously supported, but how do you go about first requiring a number be known without already knowing it (hash it I'd guess), and then what OP code do you use to verify it?

fair.

I've gone through the aforementioned thread just to found out that the description
in the above link was just the initial prototype. Dunno why blockstream didn't link
the final proposal (formalized as BIP draft) contained here:

https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki

I'm not saying that it contains the answers to all your question
but after a quick glance it seems a lot more informative.

[cypherdoc]

And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.

TBF and Blockstream are the only companies paying people to develop on Bitcoin Core.

Bitcoin Core is not the only implementation of Bitcoin.

Conformal Systems did, in fact, "put up" and received little-to-no acknowledgement for doing so. (To say nothing of all the other developers who tried to do the same thing but were not able to overcome the resistance and stonewalling via which Bitcoin Core team defends their turf)

"Shut up or put up" is a lie, because as soon as somebody actually does it the goal posts promptly move.

actually, what happens if SPVproof gets added to Bitcoin Core but BTC-d ignores it?

edit:  or libbitcoin or BitcoinJS for that matter?

[brg444]

i hate articles like these, esp from guys like J Levin who i think is generally respected in the community b/c of his Oxford CS training and Coinometrics.  i however have not been impressed with his previous thinking as he is one of the geeks who doesn't fully get Bitcoin:

https://medium.com/@jony_levin/i-love-the-blockchain-just-not-bitcoin-354c511ad3e5

same reason, same hate from me:  he implies that the Bitcoin currency unit can be changed or that it can somehow be replaced or added to with another token (currency unit).  he then doesn't even mention how tx fees can make up for lost blockchain security incentives after a block halving which is a disingenuous and incomplete discussion.  a mention that tx fees "need and can" increase to compensate for decreasing block reward would have been totally appropriate and complete.

this is still a problem i have with making protocol changes; how do you insert a protocol change that doesn't favor a certain group of ppl or disadvantage the ppl that have come before the change?  b/c Bitcoin is an open community, outside voices are allowed to be heard loud and clear.  however, we never know to what extent they are personally invested in the former rule set (protocol) as opposed to the new rule set they are proposing.

I'm not certain what problem you have with his article?

Where does he implies that the Bitcoin currency unit can be changed? In his conclusion ("it this does not have to be the case forever.") ?

It seems to me you have misunderstood the premise of his article. When he mentions :

I would like to push for blockchains with native tokens rather than just blockchains (innovative, probabilistically immutable databases) which have far lower utility if any.

He is not supporting or demanding the creation of different blockchains but merely implying that the use of the blockchain technology necessitate a native token. He then demonstrates why it is so and confirms the importance of the Bitcoin unit.

He very much supports the arguments you, and most of us, have championed in this thread.

[justusranvier]

actually, what happens if SPVproof gets added to Bitcoin Core but BTC-d ignores it?

edit:  or libbitcoin or BitcoinJS for that matter?

Same with any other change to the protocol:

The economic majority will decide.

If an economic majority upgrades to the new Bitcoin Core version, their fork will win.

If an economy majority stays with old Bitcoin Core versions or switches to btcd, then their fork will win.

Anybody who cares about Bitcoin in a positive way won't roll out changes which threaten to cause a tie, or even anything but a near-universal agreement.

[cypherdoc]

i hate articles like these, esp from guys like J Levin who i think is generally respected in the community b/c of his Oxford CS training and Coinometrics.  i however have not been impressed with his previous thinking as he is one of the geeks who doesn't fully get Bitcoin:

https://medium.com/@jony_levin/i-love-the-blockchain-just-not-bitcoin-354c511ad3e5

same reason, same hate from me:  he implies that the Bitcoin currency unit can be changed or that it can somehow be replaced or added to with another token (currency unit).  he then doesn't even mention how tx fees can make up for lost blockchain security incentives after a block halving which is a disingenuous and incomplete discussion.  a mention that tx fees "need and can" increase to compensate for decreasing block reward would have been totally appropriate and complete.

this is still a problem i have with making protocol changes; how do you insert a protocol change that doesn't favor a certain group of ppl or disadvantage the ppl that have come before the change?  b/c Bitcoin is an open community, outside voices are allowed to be heard loud and clear.  however, we never know to what extent they are personally invested in the former rule set (protocol) as opposed to the new rule set they are proposing.

I'm not certain what problem you have with his article?

Where does he implies that the Bitcoin currency unit can be changed? In his conclusion ("it this does not have to be the case forever.") ?

It seems to me you have misunderstood the premise of his article. When he mentions :

I would like to push for blockchains with native tokens rather than just blockchains (innovative, probabilistically immutable databases) which have far lower utility if any.

He is not supporting or demanding the creation of different blockchains but merely implying that the use of the blockchain technology necessitate a native token. He then demonstrates why it is so and confirms the importance of the Bitcoin unit.

He very much supports the arguments you, and most of us, have championed in this thread.

you may be right.  i had a little trouble ascertaining the article's true message while in a rush.

i think it was this part: "it this does not have to be the case forever."  and this part which i said above:

he then doesn't even mention how tx fees can make up for lost blockchain security incentives after a block halving which is a disingenuous and incomplete discussion.  a mention that tx fees "need and can" increase to compensate for decreasing block reward would have been totally appropriate and complete.

when someone makes an error of omission that is so basic like he did, i immediately become suspicious.  he should know better.

[thezerg]

I think other corde devs can keep core devs in Blockstream in check.  And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.  Frankly, if you have a problem with it, then shut up and put up.  Put up BTC (and/or encourage others to do so) to fund a core dev.  You don't need permission.  Just start paying a great developer and he'll become a core dev once he proves his worth.

And there's another thing that I like about sidechains.  Lately, I hear about cool technologies... for example maidsafe distributed storage, and the zen-something public supercomputer... and get excited.  And then I hear about their stupid pump and dump alt-coin that you have to use and its a pretty big letdown.  

look at the JLevin article i just put up.  he's moving in the opposite direction as you, it appears, in regards to "tokens".

Sidechains would give no excuses to create these app-specific coins -- or what I mean is that an honest company would create a Sidechain with pegged currency to take advantage of blockchain technology but avoid accusations and temptations to pump and dump.  And also, a Sidechain will avoid the likely SEC inquiry as issuing the coin before it has any use whatsoever (before your product is done) starts to make it look a lot like a security.

so what's the financial incentive for a company to create a SC with 2wp w/o a token?

Yes, the concept of a blockchain is great.  A single, open, universal unit of account is great, and Bitcoin will likely out-compete all others simply due to network effect -- causing alt-scam anguish in these app-coins even if that wasn't the original intention.  But the blockchain as defined by Bitcoin is overly limited.  Its been obvious since early 2012 that the bitcoin blockchain has a serious problem and that is it can only do trustless transfer, not trustless exchange.  Therefore all the Bitcoin 2.0 stuff.

Sidechains give us Bitcoin the currency, and the blockchain without locking us to one particular blockchain implementation.


Financial incentive:  Exactly!  We can't determine the financial incentive without knowing what the company does.  In other words, the financial incentive is going to be getting paid for whatever real value that company delivers, not due to appreciation or speculation of some app-coin token.  

Trivial example: you could create a document registration company.  Company creates a registrar sidechain with some modifications to add document registration data fields and retention time.  To use it every transaction has to transfer .0001 scBTC to the company, per year retained.  And as a bonus no BTC dev is whining about BTC blockchain spam.  Company makes additional $ with related services like testifying in court.  Sounds like not much money?  But e-bank statements have always been bullsh*t.  "Click here" to see the bank statement today, click tomorrow and you may see something completely different because the company's web server serves the statement.  Every e-statement worldwide should move to a blockchain based validation system.  Those .0001 BTCs would add up pretty quickly.  But if on the Bitcoin blockchain it would seriously hamper Bitcoin scalability -- note my registrar sidechain has a retention time -- old blocks can be forgotten.

[cypherdoc]

I think other corde devs can keep core devs in Blockstream in check.  And the fact of the matter is that this company and TBF are the only things keeping paid developers working on Bitcoin.  Frankly, if you have a problem with it, then shut up and put up.  Put up BTC (and/or encourage others to do so) to fund a core dev.  You don't need permission.  Just start paying a great developer and he'll become a core dev once he proves his worth.

And there's another thing that I like about sidechains.  Lately, I hear about cool technologies... for example maidsafe distributed storage, and the zen-something public supercomputer... and get excited.  And then I hear about their stupid pump and dump alt-coin that you have to use and its a pretty big letdown.  

look at the JLevin article i just put up.  he's moving in the opposite direction as you, it appears, in regards to "tokens".

Sidechains would give no excuses to create these app-specific coins -- or what I mean is that an honest company would create a Sidechain with pegged currency to take advantage of blockchain technology but avoid accusations and temptations to pump and dump.  And also, a Sidechain will avoid the likely SEC inquiry as issuing the coin before it has any use whatsoever (before your product is done) starts to make it look a lot like a security.

so what's the financial incentive for a company to create a SC with 2wp w/o a token?

Yes, the concept of a blockchain is great.  A single, open, universal unit of account is great, and Bitcoin will likely out-compete all others simply due to network effect -- causing alt-scam anguish in these app-coins even if that wasn't the original intention.  But the blockchain as defined by Bitcoin is overly limited.  Its been obvious since early 2012 that the bitcoin blockchain has a serious problem and that is it can only do trustless transfer, not trustless exchange.  Therefore all the Bitcoin 2.0 stuff.

Sidechains give us Bitcoin the currency, and the blockchain without locking us to one particular blockchain implementation.


Financial incentive:  Exactly!  We can't determine the financial incentive without knowing what the company does.  In other words, the financial incentive is going to be getting paid for whatever real value that company delivers, not due to appreciation or speculation of some app-coin token.  

Trivial example: you could create a document registration company.  Company creates a registrar sidechain with some modifications to add document registration data fields and retention time.  To use it every transaction has to transfer .0001 scBTC to the company, per year retained.  And as a bonus no BTC dev is whining about BTC blockchain spam.  Company makes additional $ with related services like testifying in court.  Sounds like not much money?  But e-bank statements have always been bullsh*t.  "Click here" to see the bank statement today, click tomorrow and you may see something completely different because the company's web server serves the statement.  Every e-statement worldwide should move to a blockchain based validation system.  Those .0001 BTCs would add up pretty quickly.  But if on the Bitcoin blockchain it would seriously hamper Bitcoin scalability -- note my registrar sidechain has a retention time -- old blocks can be forgotten.

re: scalability.  but this is what Gavin's block size expansion proposal is supposed to address.