So I have a hypothetical situation, and I’m interested in this community’s input, this is the economic speculation thread after all.
lets say someone has 1% of all Bitcoin.
lets say they create a Bitcoin ETF, and sell shares to that ETF on the NASDAQ. It takes off. Over time the holding in the ETF go up and down the total holdings never Drop below 1%
In this scenario the ETF Charter promise to back the ETF with Bitcoin it guarantees on redemption to pay in USD at market rate and only under special circumstances will it pay out in BTC.
---
In this hypothetical situation an SC-coin-it has been created, it is Open Source, it has proven utility and security, faster transfer times, it is highly liquid, in fact it is the preferred transfer of value coin for salary’s and typical larger expenses like TV’s and high end consumer goods because of its faster confirmation times, People still use Bitcoin for purchases like cars and houses – and even pay their loans in BTC – yacht for BTC are selling will in this hypothetical scenario, in fact BTC is used for larger deals where instant transfer times are not a risk. But the SC-coin-it is the preferred means of exchange for anything of value that is relinquished at the point of sale.
What happens when the ETF, knowing they have 1:1 2wp redemption capability with the SC-coin-it, and 1% of all bitcoins that are stagnant start to leverage their BTC, they are still in theory backed by BTC, but start lending out SC-coin-it to AAA rated entities, they haven't broken there charter due the technicality that the BTC is secure, and they are not lending their BTC ?
Topic: Gold collapsing. Bitcoin UP. - page 754. (Read 2032266 times)
But everything what humans can verify computer can too. :-) => and bitcoin can do.
well now, see, this is what NL was referring to. hyperbole.
i personally don't think computer's can do everything. there are going to be times when humans need to intervene. in fact, computers do what humans tell them to do most of the time and if that is fraud, computers will commit fraud.
these are the things i worry about with Blockstream. they stand to make alot of money on this.
Yes, I agree. It is not easy to create the process (sequence of tasks and transaction that must be verifiable by computer). But I think, it is achievable. If you know how to do it better then you are free to do it (for free or for more money).
Bitcoin is open source, everybody can make changes and run their own clone (we already have thousands of alt-clones). Profit or non-profit company can create whitepaper and implement new changes. Users and miners can choose if it makes sense to use or not.
And it is only beginning, more for-profit companies comes in next years.
But everything what humans can verify computer can too. :-) => and bitcoin can do.
well now, see, this is what NL was referring to. hyperbole.
i personally don't think computer's can do everything. there are going to be times when humans need to intervene. in fact, computers do what humans tell them to do most of the time and if that is fraud, computers will commit fraud.
these are the things i worry about with Blockstream. they stand to make alot of money on this.
cypherdoc, Is not SC amazing ? They can do what they want, they only have to deliver cryptographic PROOF to MC miners.
- cypherdoc moved X coins to SC -> we have his signature
- cypherdoc spend Y coins in SC -> we have his signature
- cypherdoc wants X-Y BTC -> it is ok we have his signature
- cypherdoc moved X coins to SC -> we have his signature
- cypherdoc spend Y coins in SC -> we have his signature
- cypherdoc wants X-Y BTC -> it is ok we have his signature
we still need to see all the details on how these are constructed.
given all the different abbreviations mixed with your english, half the time i don't understand what you're saying, btw.
I'm sorry for my english, I'm not native speaker. But everything what humans can verify computer can too. :-) => and bitcoin can do.
Quote
The required expressiveness could be added in a safe, compatible, and highly compartmentalised way ( e.g. , by converting a no-op instruction into an OP_SIDECHAINPROOFVERIFY in a soft-fork). However, the difficulty of building consensus for and deploying even simple new features is non-trivial.
...
Fortunately, by adopting some additional security assumptions at the expense of the low trust design objective, it is possible to do an initial deployment in a completely permissionless way. The key observation is that any enhancement to Bitcoin Script can be implemented externally by having a trusted federation of mutually distrusting functionaries evaluate the script and accept by
signing for an ordinary multisignature script. That is, the functionaries act as a protocol adaptor
by evaluating the same rules we would have wanted Bitcoin to evaluate, but cannot for lack of script enhancements. Using this we can achieve a federated peg.
...
Fortunately, by adopting some additional security assumptions at the expense of the low trust design objective, it is possible to do an initial deployment in a completely permissionless way. The key observation is that any enhancement to Bitcoin Script can be implemented externally by having a trusted federation of mutually distrusting functionaries evaluate the script and accept by
signing for an ordinary multisignature script. That is, the functionaries act as a protocol adaptor
by evaluating the same rules we would have wanted Bitcoin to evaluate, but cannot for lack of script enhancements. Using this we can achieve a federated peg.
cypherdoc, Is not SC amazing ? They can do what they want, they only have to deliver cryptographic PROOF to MC miners.
- cypherdoc moved X coins to SC -> we have his signature
- cypherdoc spend Y coins in SC -> we have his signature
- cypherdoc wants X-Y BTC -> it is ok we have his signature
- cypherdoc moved X coins to SC -> we have his signature
- cypherdoc spend Y coins in SC -> we have his signature
- cypherdoc wants X-Y BTC -> it is ok we have his signature
we still need to see all the details on how these are constructed.
given all the different abbreviations mixed with your english, half the time i don't understand what you're saying, btw.
cypherdoc, Is not SC amazing ? They can do what they want, they only have to deliver cryptographic PROOF to MC miners.
- cypherdoc moved X coins to SC -> we have his signature
- cypherdoc spend Y coins in SC -> we have his signature
- cypherdoc wants X-Y BTC -> it is ok we have his signature
- cypherdoc moved X coins to SC -> we have his signature
- cypherdoc spend Y coins in SC -> we have his signature
- cypherdoc wants X-Y BTC -> it is ok we have his signature
pg 20 Implementation
why would an attacker have to fake a block when faking a SPV proof (tx)? blocks are created by miners...
still don't see a section 8 on pg 5
why would an attacker have to fake a block when faking a SPV proof (tx)? blocks are created by miners...
still don't see a section 8 on pg 5
This section 8:
https://bitcoin.org/bitcoin.pdf
Referring to the headers.
Apologies if this was answered answered previously.
brg444, how do you want to implement fastBTC using MM ?
In all honesty that type of design question is out of my technical range.
I understand from your posts there are different ways to go about it and I'm certainly not knowledgeable enough to pretend to know which one would be best.
I'm certainly interested in hearing what you have in mind though..
I think that this service will use HUGE amount of small transactions
1) split into 1000 local providers
2) or maybe at the and of month return btc to all participants and start fresh blockchain.
for a particular scBTC A that originates from SPV proof A, doesn't that scBTC A have to go back thru SPV proof A to get back to BTC? in other words, scBTC A couldn't go back thru SPV proof B and aren't fungible in terms of the proofs?
If you move your scBTC into address you do not own pKeys you cannot reclaim this btc back.
a) so service could start new side-b-blockchain
b) you can swap into new side-b-blockchain or reclaim btc (but you must own sidePKey)
fastWallet can ask you and offer -> reclaim BTC or swap in new side-blockchain
edit:
You will have to sign in SC-a move to BTC(use btc address) or move to SC-b(use scBTC-b address)
edit2:
Or service automatically use their own bitcoin to create new 2wp BTC to scBTC-b and automatically swap to your original scBTC-a address.
Side chains per se, do not solve all the problems Bitcoin has today, nor are they a guarantee of anything.
What they are is a mechanism. They may have the potential to solve problems. That will depend entirely on what people do with them. They are another tool in the tool belt. It can be used to build or destroy. The existence of this mechanism does not guarantee the success of Bitcoin. It would be nice if it did, and we could all just sit back and wait for the magic to happen.
I completely agree, I'm sorry if I used a worse wording, I think the problem is I'm not a native English speaker and this has effects What they are is a mechanism. They may have the potential to solve problems. That will depend entirely on what people do with them. They are another tool in the tool belt. It can be used to build or destroy. The existence of this mechanism does not guarantee the success of Bitcoin. It would be nice if it did, and we could all just sit back and wait for the magic to happen.
Quote
Instead there is a new tool, a new mechanism. It may be used by all sorts of people, and groups. This is great, it is the nature of open source collaboration. However we must recognize that only some people may share common goals with you or me, and others may not. And you may not know whether any particular SC creator does or doesn't. There may be wolves in alpaca clothing.
Again, I agree... and "wolves in alpaca clothing" is fantastic 
I'll take this expression as mine henceforth, if you don't mind Quote
These are the sorts of things that I (and presumably CypherDoc and others) consider with caution. What makes this even more of a concern is when we see these posts that essentially say "there is nothing to worry about", "this fixes everything" or "the details of the cryptography don't matter".
Those sort of statements are either (a) just misunderstood word choices (and something else was meant by the author), or (b) maybe the author is simply misguided or exuberant , or (c) perhaps they may be malicious attempts to misguide others.
[...]
What you wrote here below is sensible. We may disagree on some matters of preference, but I like that you say what side chains "can" do rather than what they "will" do. It is important to understand that they can be used and also can be abused.
Again, I completely agree.Those sort of statements are either (a) just misunderstood word choices (and something else was meant by the author), or (b) maybe the author is simply misguided or exuberant , or (c) perhaps they may be malicious attempts to misguide others.
[...]
What you wrote here below is sensible. We may disagree on some matters of preference, but I like that you say what side chains "can" do rather than what they "will" do. It is important to understand that they can be used and also can be abused.
The problem is that while I understand they can be abused, I also understand that the problem they can create is one of these two types:
1) an altcoin. Yes, that can be a problem, but it's not a different problem than the one we have right now.
2) a service that fails. Let's remember that a 2wp sidechain is a service completely analogous to the one offered today by a coinbase or a mtgox. We know they can add value to the network, and we know they can fail bringing enormous problems to their users, but they can't harm bitcoin, the network. That's why I consider SC an improvement to the actual situation, and it's because we have an algorithm to programmatically move coins between the chain.
And that movement can be done without requesting permission.
That's not a minor improvement: that's the difference between day and night, and one that can solve a lot of problems, like for example the fractional reserve of mtgox.
Quote
I think Cypherdoc is understanding the function and capabilities pretty well. I also think his caution is reasonable.
I agree that caution is reasonable, and I'm eager to understand the failure cases, but simply I don't find any evidence, not from cypherdoc, in any case.A cursory rereading of that section still leaves me with some questions, but I'll try to remember to come back and look into the reference Pug90 when I'm not busy.
An SPV proof is a tx + block headers that prove the tx has been accepted by SC miners. They can't fake a proof without forging the transaction into a SC block.
bitcoin.pdf section 8
@cypherdoc
Notme is using
https://bitcoin.org/bitcoin.pdf
(I do not know it is same SPV proof as SC whitepaper uses)
Edit:
yes, it is same
- snip - image of mining rigs (?) in a barn of some sort - makes post to big -
I think that's more a case of a wealthy amateur job going wrong
Gone right in my opinion. I would feel vastly more confident in my BTC with 10,000 of these spread all over the globe than I would with five of these spread around the U.S. and a few in Western Europe for backup:
brg444, how do you want to implement fastBTC using MM ?
In all honesty that type of design question is out of my technical range.
I understand from your posts there are different ways to go about it and I'm certainly not knowledgeable enough to pretend to know which one would be best.
I'm certainly interested in hearing what you have in mind though..
I think that this service will use HUGE amount of small transactions
1) split into 1000 local providers
2) or maybe at the and of month return btc to all participants and start fresh blockchain.
for a particular scBTC A that originates from SPV proof A, doesn't that scBTC A have to go back thru SPV proof A to get back to BTC? in other words, scBTC A couldn't go back thru SPV proof B and aren't fungible in terms of the proofs?
....
Then we agree.Side chains accommodate arbitrary crypto (good bad or ugly) and which crypto is used for a particular chain matters.
It is my understanding that while the transactions can use arbitrary crypto, block hashing would be limited to sha256 (or possibly a small list of others). In order to ensure a malicious attacker can not simply lie, the bitcoin miners supporting SPV proofs will need to verify the block hash is valid for the headers provided. The transaction's details that destroy the pegged coin and unlock the bitcoin will be used, but the signature can be trusted since it is in the block with the highest amount of work. If nobody presents a higher difficulty block header that contains a contradicting transaction within the contest period, the bitcoins unlock. But, to verify all this, the miners must be able to hash the headers.
Is it possible for attackers to do this in reverse?
Take someone's cold wallet and lock them into an SPVPROOF on a SC while the true owner is indisposed for some reason? Or is this impossible because they would need the private keys to begin with?
Presumably the sidechain would still require a valid signature to allow a transaction in a block.
you mean the SC block? yes, don't these SPV proofs require 2 tx's each, one in MC and one in SC?
Quote
Essentially, what you are dealing with is a set of headers and a transaction. The headers prove the transaction was added to a block. (See section 8 of bitcoin.pdf).
there is no section 8
Quote
What the sidechains idea adds is that instead light node verifying a bitcoin transaction, the bitcoin miners verify that the sidechain has a transaction that destroys sidecoins. If this transaction goes uncontested, the SPV proof is accepted and the previously locked bitcoins are sent to the address specified in the destroy transaction.
i asked you before about this contest period. what is the probability of an attacker constructing a fake proof in either direction.
Quote
what is this all about? isn't this a fundamental change to how Bitcoin blocks are linked together?
We require a change to Bitcoin so that rather than each blockheader committing only to the
header before it, it commits to every one of its ancestors.
Yes a SC block. Yes, there needs to be a destroy transaction on SC and a SPV proof on MC.
Did you try looking between sections 7 and 9? That's where I found section 8. (Hint, page 5).
An attacker can only fake a proof if they can fake a block, so it is up to the security model of the sidechain.
Can you put that quote in context (where is it in which whitepaper?).... I'm not sure quite what they are referring to.
pg 20 Implementation
why would an attacker have to fake a block when faking a SPV proof (tx)? blocks are created by miners...
still don't see a section 8 on pg 5
A cursory rereading of that section still leaves me with some questions, but I'll try to remember to come back and look into the reference Pug90 when I'm not busy.
An SPV proof is a tx + block headers that prove the tx has been accepted by SC miners. They can't fake a proof without forging the transaction into a SC block.
bitcoin.pdf section 8
brg444, how do you want to implement fastBTC using MM ?
In all honesty that type of design question is out of my technical range.
I understand from your posts there are different ways to go about it and I'm certainly not knowledgeable enough to pretend to know which one would be best.
I'm certainly interested in hearing what you have in mind though..
I think that this service will use HUGE amount of small transactions
1) split into 1000 local providers
2) or maybe at the and of month return btc to all participants and start fresh blockchain.
actually, that may not be true. hardware is entering commoditization and the cost of hashing has dropped 10 fold in the last year. so there may be some hope for solo mining still. or at least for individuals holding hardware that want to pool mine.
did you see this: over $3.6M in hardware, one of the risks of centralized mining, the guy was consuming 5.5MW of power and only had 2 security grads.
link? wow, that looks like that Chinese mine with huge fans in opposite walls?
I flowed up on BT last night and there are a few other threads.
goes to show you there are risks to centralization.
I think that's more a case of a wealthy amateur job going wrong
After seeing some more pictures I have to take that back. It is suggested the fire did not originate from the miners. Setup looked fine
brg444, how do you want to implement fastBTC using MM ?
In all honesty that type of design question is out of my technical range.
I understand from your posts there are different ways to go about it and I'm certainly not knowledgeable enough to pretend to know which one would be best.
I'm certainly interested in hearing what you have in mind though..
brg444, how do you want to implement fastBTC using MM ?
Edit:
I think it is only possible by splitting into more(1000) SCs
Edit:
I think it is only possible by splitting into more(1000) SCs
actually, that may not be true. hardware is entering commoditization and the cost of hashing has dropped 10 fold in the last year. so there may be some hope for solo mining still. or at least for individuals holding hardware that want to pool mine.
did you see this: over $3.6M in hardware, one of the risks of centralized mining, the guy was consuming 5.5MW of power and only had 2 security grads.
link? wow, that looks like that Chinese mine with huge fans in opposite walls?
I flowed up on BT last night and there are a few other threads.
goes to show you there are risks to centralization.
I think that's more a case of a wealthy amateur job going wrong
actually, that may not be true. hardware is entering commoditization and the cost of hashing has dropped 10 fold in the last year. so there may be some hope for solo mining still. or at least for individuals holding hardware that want to pool mine.
did you see this: over $3.6M in hardware, one of the risks of centralized mining, the guy was consuming 5.5MW of power and only had 2 security grads.
link? wow, that looks like that Chinese mine with huge fans in opposite walls?
I flowed up on BT last night and there are a few other threads.
goes to show you there are risks to centralization.
actually, that may not be true. hardware is entering commoditization and the cost of hashing has dropped 10 fold in the last year. so there may be some hope for solo mining still. or at least for individuals holding hardware that want to pool mine.
did you see this: over $3.6M in hardware, one of the risks of centralized mining, the guy was consuming 5.5MW of power and only had 2 security grads.
link? wow, that looks like that Chinese mine with huge fans in opposite walls?
I flowed up on BT last night and there are a few other threads.
Jump to: