tvbcof
Legendary
Online
Activity: 4704
Merit: 1276
|
|
January 04, 2015, 06:23:15 PM |
|
I've always been more inclined to favor more of a token system for 'exchange currency' duty. Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand. For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.
I guess I didnt understand what you meant then (I was thinking privacy). Still not getting it. Adam I had mis-read that somehow cypherdoc was anticipating sidechain data in the mainchain. One of the reasons I was against this was privacy. Even a correct reading that there was total transparency within a sidechain system (including at the Bitcoin nexus) has some privacy negatives which I would (for many uses) prefer to avoid when possible. As I stated, as long as I as a user can be confident that I have 'sole control' of my value in a sidechain, that is all I need. I do think that people from the top to the bottom tend to get tunnel vision and assume a blockchain architecture to be the only considered solution. I never did. I consider it a wonderful solution for 'reserve' duty (often because of the transparency features which are a double-edged sword), but simply not a good match for 'exchange' duty. Your pal Rusty fell into this trap IMHO though I very much appreciate his conceptions of slop...they guy must be an engineer On a theoretical level (mine), tokenized solutions: - nix the latency hassles associated with blocks - are inherently efficient since the allow 'nature' to be balance sheet which nobody need care about in minute detail. - promote (potentially, depending on implementation) privacy due to this lack of need for minute detail accounting. The change jingling around in one's pocket is a good example of a 'tokenized' system and it works fantastically. One might say it works 'to well' for some people's tastes and don't know how much longer old-style currency will be hanging on in our modern digital world.
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
Adrian-x
Legendary
Offline
Activity: 1372
Merit: 1000
|
|
January 04, 2015, 06:30:36 PM |
|
If mtgox had had you design a SC for them, would you have structured a single specific SPVmtgox SC to which everyone would have sent their BTC (one address), then waited 2d for confirmation, before allowing those individuals to be assigned their own specific scBTC to be traded p2p , all the while securing this SC with 100% MM?
The point of moving transactions on-chain is that the user can then own their own coins, rather than delegating ownership to a third party like mtgox. Adam Adam why not support OT. With SC as proposed users don't own there one coin they are trusting the decentralized network managed by pitting incentives to secure the coins. SC proponents overlook the change SC make to the incentive system and think it's safe. I'm open to changing my mind, why don't you put some of that $21m into a peer review economic impact study? The nonsense you spout about where your profit comes from is damaging to BlockStream's motives.
|
Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
|
|
|
adam3us
|
|
January 04, 2015, 06:37:58 PM Last edit: January 04, 2015, 06:51:39 PM by adam3us |
|
I've always been more inclined to favor more of a token system for 'exchange currency' duty. Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand. For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.
none of what you're saying then makes sense compared to what Adam has been saying. SC's are blockchains except in the case of federated server SC's (but even that definition is being fuzzed over by the SC ppl calling an internal ledger a SC ) I think it was more JorgeStolfi with the internal ledger (the sofa/couch in bitstamps office?), I would not call an internal ledger a chain - a chain has to be real-time publicly audited I think, to be called a chain. With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes there too, so they release the funds to the address the return peg tells them to. Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain. But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
tvbcof
Legendary
Online
Activity: 4704
Merit: 1276
|
|
January 04, 2015, 06:49:36 PM |
|
Adam why not support OT. ...
Maybe for the same basic reason you don't get into the car with the nice man who offers you candy.
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
JorgeStolfi
|
|
January 04, 2015, 06:49:55 PM |
|
What is it exactly that prevents those potential COIN buyers from buying BTC directly, or SMBIT shares? The fact that they are not traded on an exchange like NASDAQ? Or some intrinsic property of the asset?
Note that COIN shares will uninsured against theft or loss, besides being backed only by a "stock" (BTCs) that itself has no backing assets.
Permit me to quote myself from another thread..... One point that's been overlooked in this discussion: ETFs allow institutional and qualified/professional investors to purchase regulated securities, pursuant either to their own internal bylaws and product placement memoranda, or to securities laws by which they must abide. For example, a professional investment fund, such as a mutual fund or hedge fund or pension fund, is limited in how it may allocate investors' funds insofar as the fund is only permitted to purchase securities regulated under such-and-such provisions. A fund may indeed wish to purchase bitcoins right now, but it cannot due to the aforesaid regulatory provisions; however an ETF investment vehicle would allow the fund to purchase shares in the bitcoin ETF right now, shares that would presumably track the Bitcoin price, and may be bought, sold, and traded—in a regulated environment—as any other shares would be.
Well, my question above was not rhetorical. Is the fact that the ETF is listed on NASDAQ sufficient to enable those restricted investments? Or are there other conditions that depend on the nature of the fund and its assets?
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
MarketNeutral
|
|
January 04, 2015, 06:52:13 PM |
|
I've always been more inclined to favor more of a token system for 'exchange currency' duty. Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand. For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.
none of what you're saying then makes sense compared to what Adam has been saying. SC's are blockchains except in the case of federated server SC's (but even that definition is being fuzzed over by the SC ppl calling an internal ledger a SC ) I think it was more JorgeStolfi with the internal ledger (the sofa/couch in bitstamps office?), I would not call an internal ledger a chain - a chain has to be real-time publicly audited I think, to be called a chain. With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes so they release the funds to the address the return peg tells them to. Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain. But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg. Adam Adam, would you mind clarifying a few things? I do understand the core blockchain system quite thoroughly, but these side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork? But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous? Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?
|
|
|
|
JorgeStolfi
|
|
January 04, 2015, 06:59:36 PM |
|
picolo, TonyT, there are VERY precise statistics of exactly this (just not by "person", only by "bitcoin"). All of the data is in the block chain. Anyone can see precisely when every bitcoin was last transferred. There are also pretty good data on exchange rates to whatever your favorite currency is (if not bitcoin). Every UTXO exists in a timestamped block. Ratcliff has put together some nice area charts showing the age. http://www.reddit.com/r/Bitcoin/comments/2n205b/an_area_chart_showing_the_distribution_of/So to answer your question, most bitcoin were last transferred at well under the current price. Note that the most recent transaction may not be when the coins last changed hands. If the price had been increasing all the time, the output amount X in an UTXO times the price P(t) at that time would be only an upper bound to the purchase price of those coins. However, because of the subtantial drops in price, and the large trade volumes during price drops, not even that is true. Moreover, coins that are deposited on the exchanges are changing hands without a corresponding record in the blockchain.
|
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
MarketNeutral
|
|
January 04, 2015, 07:08:03 PM |
|
What is it exactly that prevents those potential COIN buyers from buying BTC directly, or SMBIT shares? The fact that they are not traded on an exchange like NASDAQ? Or some intrinsic property of the asset?
Note that COIN shares will uninsured against theft or loss, besides being backed only by a "stock" (BTCs) that itself has no backing assets.
Permit me to quote myself from another thread..... One point that's been overlooked in this discussion: ETFs allow institutional and qualified/professional investors to purchase regulated securities, pursuant either to their own internal bylaws and product placement memoranda, or to securities laws by which they must abide. For example, a professional investment fund, such as a mutual fund or hedge fund or pension fund, is limited in how it may allocate investors' funds insofar as the fund is only permitted to purchase securities regulated under such-and-such provisions. A fund may indeed wish to purchase bitcoins right now, but it cannot due to the aforesaid regulatory provisions; however an ETF investment vehicle would allow the fund to purchase shares in the bitcoin ETF right now, shares that would presumably track the Bitcoin price, and may be bought, sold, and traded—in a regulated environment—as any other shares would be.
Well, my question above was not rhetorical. Is the fact that the ETF is listed on NASDAQ sufficient to enable those restricted investments? Or are there other conditions that depend on the nature of the fund and its assets? Yes, NASDAQ is more than sufficient. Generally speaking, any security listed on a major exchange, such as NASDAQ or DJIA, is considered adequately regulated for institutional and professional investment purposes. Another way to look at it is, in the United States for example, if the SEC, FINRA, DTCC, or NASAA are involved, then the investments are in theory permissible on a professional level. Similar regulatory boards and enforcement agencies in other countries operate in much the same way. There are exceptions, mostly contingent upon the nature of the fund that's investing and other factors such as the clients' risk profile or initial investment amount. There are plenty of professional investors who would love to invest in exotic, high-risk instruments such as Bitcoin, but they also know that if they don't follow the law, i.e., investing clients' funds in regulated securities markets, then they can easily be sued and shuttered into oblivion. At the highest levels of finance, most of what investors spend there time on is considering investments against possible litigation.
|
|
|
|
tvbcof
Legendary
Online
Activity: 4704
Merit: 1276
|
|
January 04, 2015, 07:21:25 PM Last edit: January 04, 2015, 07:48:54 PM by tvbcof |
|
Adam, would you mind clarifying a few things? I do understand the core blockchain system quite thoroughly, but these side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork? But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous?
Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?
If you would allow me to chime in only because it offers an opportunity to propose REAL potential problems with sidechains and not phony simplistic self-serving nonsense ones. As I see things, sidechains effect Bitcoin simply as large, well funded, often fairly active whales. Nothing more, and it doesn't matter how they work in their own back-ends (chains, tokens, ledgers, distributed, proprietary, whatever.) These whales happen to really really really want Bitcoin to work because their lives depend on it (with one exception shown below.) Problems: 1) being well-funded, the whales could crowd out other users of native Bitcoin. 2) these whales might get into battles with one another and try to use native Bitcoin as a cudgel causing collateral damage. 3) One whale might become so successful it may at least think it can swallow Bitcoin whole and take over (what I call 'shooting the moon.') edit - 4) A 'seismic event' within a sidechain could create a undesirable transient in native Bitcoin activity. I'll defer to Adam on the number of sidechain implementations he sees. He's stated it as a small integer as I recall. I would hope for many more in part because it would help to mitigate against some of the potential problems I see.
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
adam3us
|
|
January 04, 2015, 07:55:16 PM |
|
Oh boy, thats another can of worms. You dont happen to work for conformal do you btw?
So (it a long story) but a) no one knows who's funding them; b) most of them seem to have ex-defence contractor profiles; c) no one knows why they are coding it; d) if there is one off by even a single bit interpretation bug in it it breaks consensus and forks bitcoin, which can likely be systematically abused, to create a massive accounting/double-spend mess that will be too expensive to repair as last time - that could create a mega fork worse than the leveldb bug, and kill bitcoin or force some really harsh choices to best effort cleanup where there are innocent losers; e) it apparently took a lot of effort by the core devs to persuade them that this was a problem; f) it still has that problem.
d) This is a complete red herring and exists just as much with Bitcoin Core as it does with anything else. The exact same thing can easily happen (and already has as you've noted) with Bitcoin Core. This is a real problem with the technology that needs to be solved independent of the number of implementations on the network. In fact, working toward solutions which address this fundamental issue is necessary for Bitcoin Core too since it means mistakes there don't lead to undesirable consequences either. The current approach is "well let's just hope it doesn't happen!" and frankly, that just isn't good enough. about why consensus is hard, and more so for two different implementations, here are two presentations first on language security as it applies to host security and software compatibility and second on bitcoin consensus. The first is quite eye opening even for security researchers (ie people who are experts in host security). language security https://archive.org/details/The_Science_of_Insecurity_bitcoin consensus programming https://www.youtube.com/watch?v=on5ySFK0aoY#t=39m50sHave a listen, particularly to the first one and then we can discuss further (here or PM or bitcoin-dev or #bitcoin-wizards or whereever). I am genuinely interested to help resolve the discrepancy of opinion around this, as its actually to my mind significantly misunderstood, and dangerous for bitcoin. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
MarketNeutral
|
|
January 04, 2015, 07:55:50 PM |
|
Adam, would you mind clarifying a few things? I do understand the core blockchain system quite thoroughly, but these side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork? But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous?
Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?
If you would allow me to chime in only because it offers an opportunity to propose REAL potential problems with sidechains and not phony simplistic self-serving nonsense ones. As I see things, sidechains effect Bitcoin simply as large, well funded, often fairly active whales. Nothing more, and it doesn't matter how they work in their own back-ends (chains, tokens, ledgers, distributed, proprietary, whatever.) These whales happen to really really really want Bitcoin to work because their lives depend on it (with one exception shown below.) Problems: 1) being well-funded, the whales could crowd out other users of native Bitcoin. 2) these whales might get into battles with one another and try to use native Bitcoin as a cudgel causing collateral damage. 3) One whale might become so successful it may at least think it can swallow Bitcoin whole and take over (what I call 'shooting the moon.') I'll defer to Adam on the number of sidechain implementations he sees. He's stated it as a small integer as I recall. I would hope for many more in part because it would help to mitigate against some of the potential problems I see. There are many brilliant people working on crypto technologies, but they are so in love with the technology and with their own ideas, they neglect to consider how their academic, theoretical work may apply to the world of finance. After all, bitcoin directly relates to finance. Whether one considers bitcoin money or a commodity or a hybrid thereof, it unequivocally falls in the realm of finance just as much as it falls in the realm of programming, hacker culture, and crypto maths. I like all this stuff, so it's easy for me to get excited and follow along, but as a finance professional, I also see the other, sorely neglected side of the proverbial coin. The disconnect is enormous. (They would make great quants, haha.) I too often see bitcoin's brightest minds focusing on the minutiae of esoteric problems, while not unimportant, are not the immediate issues bitcoin merchants and users are interested in. Your post about a "whale" disrupting things is very interesting and not as far-fetched as some would believe. At this point, I think it's very important for people working on Bitcoin, sidechains, and all blockchain-related technologies, whatever they may be, to clearly state in lay terms WHY their work is important and necessary, which is to say, what problems their proposed solutions solve. Satoshi was very good at this. I also will defer to Adam on sidechain implementation. He seems to have an incredible and deep grasp of how they may function.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
January 04, 2015, 07:55:59 PM |
|
He thinks he can get to 100k TPS. What's the problem with doing 100k TPS on the main chain? (other than non-answers like "it's hard to do")
|
|
|
|
sgbett
Legendary
Offline
Activity: 2576
Merit: 1087
|
|
January 04, 2015, 08:03:03 PM |
|
I didn't say it *was* going to go up - as you noticed I used the word if (just like you did). There are a thousand other threads debating whether the price will go up or down.I'm not arguing that it will, so I don't know why you are bring that up.
By using if there is an implicit assumption that the contrary is also true - *if* people all sell the ETF and the price goes down it will force the BTC price down through arb.
Indeed; my apologies for the undue reading of your post. No worries, very Gentleman!
|
"A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution" - Satoshi Nakamoto*my posts are not investment advice*
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
January 04, 2015, 08:03:53 PM |
|
Some bizarre form of Tourette Syndrome If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it? There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them. Let us know how your investigation goes.
|
|
|
|
tvbcof
Legendary
Online
Activity: 4704
Merit: 1276
|
|
January 04, 2015, 08:17:25 PM |
|
Some bizarre form of Tourette Syndrome If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it? There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them. Let us know how your investigation goes. In other words ' because free market' and ' because sound money'. Typical Libertardian fallback to a non-answer. Why should I have hoped for more?
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
adam3us
|
|
January 04, 2015, 08:18:20 PM |
|
With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes so they release the funds to the address the return peg tells them to.
Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain. But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg.
[...] side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork? Right no changes needed. But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous?
Yes failure modes kick in if the threshold of federated servers is compromised or untrustworthy, and could be worse as there is more flexibility on coding smart-contract enforced limits with the spv-peg (or for now hypothetical snark-peg). Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?
Nothing changes for hw miners. Any changes are in the pool (local or remote) the miners are connected to - which fullnodes its getting merkle information from. I'd say outside of side-chains, and just in general, a soft-fork (or even 99% of conceivable hard-forks) the mining algorithm would not change. The miners just need some basic formatting about headers to continue to work and they're fine as is. I think the unlikely because of self-preservation, but main way hypothetically you'd see mining change is if miners got far too centralised and it became an disruptive day to day problem for bitcoin security, and mining operators rejected or ignored complaints, the economic majority could eventually fell forced to defensively break the current deployed ASICs with a minor software change. The so-called 'big-red-button'. Its not fun in any direction because it leads to erratic hashrate risks from the hash-rate shake up as GPUs & FPGAs are reshuffled and revised ASICs fast-tracked. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
markj113
Legendary
Offline
Activity: 2254
Merit: 1043
|
|
January 04, 2015, 08:26:23 PM |
|
Gold outperformed every currency apart from the US $ in 2014, 0.8% down on the year I think most people know how the US $ will end up so get some gold while you can
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
January 04, 2015, 08:29:33 PM |
|
Some bizarre form of Tourette Syndrome If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it? There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them. Let us know how your investigation goes. Don't bother with the simpleton. He's been operating under the assumption that SC's are token, not blockchains, lol. And what about his blather above that accounting doesn't need to pay attention to details, lol?
|
|
|
|
tvbcof
Legendary
Online
Activity: 4704
Merit: 1276
|
|
January 04, 2015, 08:37:30 PM |
|
Some bizarre form of Tourette Syndrome If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it? There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them. Let us know how your investigation goes. Don't bother with the simpleton. He's been operating under the assumption that SC's are token, not blockchains, lol. And what about his blather above that accounting doesn't need to pay attention to details, lol? I notice that cypherdoc also avoided my very simple and easy to understand question like the plague. I'll give you two a few days to come up with some sort of a plausible answer, but won't expect much more than ' because free market.' BTW, I know first hand how 'they manage to deal with it', and it's not pretty. Certainly it's not where I want to see Bitcoin go whether it makes me a fortune or not.
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
January 04, 2015, 08:43:25 PM |
|
I've always been more inclined to favor more of a token system for 'exchange currency' duty. Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand. For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.
none of what you're saying then makes sense compared to what Adam has been saying. SC's are blockchains except in the case of federated server SC's (but even that definition is being fuzzed over by the SC ppl calling an internal ledger a SC ) I think it was more JorgeStolfi with the internal ledger (the sofa/couch in bitstamps office?), I would not call an internal ledger a chain - a chain has to be real-time publicly audited I think, to be called a chain. With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes there too, so they release the funds to the address the return peg tells them to. Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain. But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg. Adam Ok, this is new info to all of here who assumed federated server implementations of SC's were just that, server based only, without blockchains. This sounds more like a Ripple type system with gateways and a blockchain.
|
|
|
|
|