Odalv
Legendary
Offline
Activity: 1414
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2015, 11:12:52 PM |
|
It is not possible. Nobody wants to change bitcoin fundamentals.
first off, usually they mean Bitcoin economic fundamentals. second, they can get away with this position b/c Bitcoin is NOT broken, despite what some are trying to make us believe. "Bitcoin is NOT broken" and nobody want to break it. I don't understand why do you try to fight the wind. Everybody can spend his money for things he wish. - people burn bitcoins in Counterparty address - people bought Ethers -> they sent bitcoins (worth millions of $) to vitalik address - and people will send money to other sidechain addresses .. especially when they can control them and withdraw back. It really is not your problem what SC will do and how many SCs will exist (it is same as nobody have to ask you for permissions to buy bitcoin). There is record in MC that some address hold some amount of bitcoins. (there is not difference between your address and SC address) => It is as simple as possible and nothing has changed for you as an investor. ( you would send tip to Blockstream b/c they made bitcoin more useful) ... :-)
|
|
|
|
adam3us
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2015, 11:13:43 PM Last edit: January 01, 2015, 11:33:01 PM by adam3us |
|
Blockstream and Monetas are essentially competitors, no?
That's nothing negative on Blockstream, it's just different -- that's all. Anyone who thinks there is competition between us lacks an understanding of what we're building and how we plan to monetize it. I welcome Blockstream's entry into this space and I think alt-coins are the ones most concerned about what they represent. Yup what fellowtraveller said. I personally am happy to donate time or code to OpenTransactions and may get time to do it sometime, its sort of on my todo list. (They have some fun possibility to use things like Chaum ecash and Brands attribute certs and ecash and I have a library that does that). The reason Monetas contracted Justus to help us build the voting pools is because he is a Bitcoin purist. Justus keeps us honest. And I think that is the same role he is playing here in this thread. Bitcoin is his highest value.
Yeah I've talked to Justus in person a little if he recalls, and also watched his presentation at one of the conferences as well as a video of a OpenTransactions security model presentation he did etc. I know he thinks in terms of bitcoin ethos so thats logic I grok. And I think what Justus is saying is, that a framework needs to be developed for any changes to Bitcoin. I think he's right that it's not good enough for changes merely to be "open source, open IP." There is a potential conflict of interest, and there is an easy way to put any concerns to rest. Justus said it best: I think this concern could be minimised if the soft fork needed to support sidechains was part of a larger clarification of the Bitcoin protocol development process.
If there was a clear process that explained what kinds of changes to the protocol are acceptable, and what kinds are not, combined with a development roadmap and a transparent sequence of steps for adding things to it, I think there would be less reason for Bitcoin users to worry about Blockstream and sidechains. I really don't think that's much to ask. Do you, Adam? sounds good to me, and you shouldnt interpret our intent to be anything otherwise, the thread is pretty long but I said eg I think the bigger picture though is its premature - we have not yet released code, nor BIP draft for community discussion and picking apart and redesigning etc before there is something to merge mine. Its also useful (maybe you said it yourself also I think) for a federated peg to operate for a while in parallel with that open design discussion for people to see how it works. You can view the federated peg as a protocol adaptor - there can still be mining occuring on the sidechain with the federated peg, just the return peg is translated into a multisig for bitcoin by the federation servers.
After that if the community can settle on a op-code for extensibility everyone is happy with people including us can try to stand up a few sidechains. If no one likes them then they wont get mined. So as you can see sidechains and the op_spv really depend on community and economic majority approval, and thats a good thing.
[kind words] And I know Justus can be blunt; Adam has been very graceful in this thread.
Thanks for the kind words. You're doing cool stuff also and thanks for the demo a while back I as pleased I managed to find you at the massive San Jose conference. Dont worry about Justus we get along just fine - its all in good humor, like I said when someone flamed him on this thread: Nah Justus is the good guy. He just flames a little, so what.
Yet it is true that Monetas is not asking for any forks in the Bitcoin protocol. Blockstream is. That's why these questions are being raised.
Yeah actually I said to Justus I wasnt really asking about Monetas funding for that exact reason, just replaying his questions to him to illustrate for him so he could think go through the analogous mental exercise of answering his own questions from with a Monetas hat on. There is an easy way to put them to rest.
trust me the discussion hasnt even started... wait until there's a proof of concept code and draft BIP for people to suggest redesigns of. This'll be an interesting and very open public discussion and community discussion. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
adam3us
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2015, 11:31:20 PM |
|
One of my primary concerns with sidechains is that this "other degree freedom" is used to work around the hard problems (such as the scalability hard fork) at the possible long-term detriment of the network. Like you said, "if sidechains were ready...you can have different blockchains with different blocksizes"; I worry that simply having this option might fragment the community such that the hard-fork to increase the blocksize limit doesn't happen. Without sufficient transactional bandwidth on the main chain, I worry that Bitcoin's SOV properties would be hurt as the "global ledger" becomes fragmented across multiple sidechains.
Doesnt bitcoin's SOV get helped by more demand for bitcoin arising from more types of transactions (eg share trades, zerocash transactions, snark contracts, micropayments, richer contract language etc)? Most people seem pretty ecstatic about sidechains for that kind of reason, bringing innovation back to bitcoin rather than in altcoins or featurecoins or altshares. Maybe one analogy would be say with gold if there was some law mandating you cant use it below some value, and you cant do more than so much trade, and you cant use it for property transactions only cash trades - that might have dented golds 6000 rule as a world currency no? Btw random question, I was meaning to ask with aethereum? Would a sidechain be a better way to make the point to ethereum that their value isnt in the feature that can be forked, but in cryptocurrencies network effect. ps I thought aethereum was awesome ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) except that if I recall it would float from bitcoin so not by quite bitcoin denominated. Bitcoin users had a perpetual right to claim their share of the coins right? I know there are some people who disagree, but I think Gavin's proposal to increase the blocksize limit inline with the historical rate of growth of internet bandwidth is a reasonable way to allow the network to scale without significantly affecting centralization.
Yeah I'm not disagreeing other than to suggest you maybe want to take it easy increasing it, eg do it a little and then do more later and monitor the situation. I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.
Its probably fair to say you want to support both because a sidechain is also a different security formula. However I think you acknowledge there are centralisation risks so that'd have to be balanced. If both were done we could see where users were willing to put transactions. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2015, 11:35:08 PM |
|
Btw random question, I was meaning to ask with aethereum? Would a sidechain be a better way to make the point to ethereum that their value isnt in the feature that can be forked, but in cryptocurrencies network effect. ps I thought aethereum was awesome ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) except that if I recall it would float from bitcoin so not by quite bitcoin denominated. Bitcoin users had a perpetual right to claim their share of the coins right? There was some discussion about the practical compromises of a perpetual right vs a limited (but not short) term right. It is an interesting distinction, though, to compare the one-time right to redeem (spinoff) vs a perpetual right to bidirectionally convert (side chain).
|
|
|
|
adam3us
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2015, 11:40:37 PM |
|
Other things also snarks can do magical things (full node validation and low bandwidth), sharding like Rusty Russel is exploring with pettycoin (its not an alt, its an approach to sharding bitcoin).
Rusty Russell? The creator of iptables/netfilter? Edit: a brief search confirmed we have another main linux kernel developer on board Ayup the one and same. He has a video up about pettycoin chain sharding https://www.youtube.com/watch?v=yzst_gChOr8. btw that is a kind of (non-pegged) sidechain and you hear him talking about a gateway or federated gateway. That is like a federated peg. (Yeah he knows its related, he's hanging out on #bitcoin-wizards and discussing pettycoin design with GMaxwell and others). (Pettycoin is a micropayment network bitcoin auxiliary chain aiming at scaling to 100k tx/sec.) Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
adam3us
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2015, 11:48:26 PM |
|
i have a suggestion, out of fairness sake. why don't we allow JR & ft, along with any other wanton altcoin/Bitcoin 2.0 dev, to insert their own highly specific op_code function into Bitcoin source code that benefits their own business model? as long as it's open source, it should be fine, right? and we shouldn't care if they are a for-profit, let alone nefarious, business; ppl can just ignore them.
There we go, thats the cypherpdoc we know ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) But seriously I wrote several hundred lines on this topic, so it'd be helpful if you have something specific you can point about what i've said that you dont find convincing, it'll make it easier for me to comment. I wrote a bit about why the op_spv is not proprietary or specific to blockstream and that idea existed before blockstream the company existed. Feel free to pick it apart or disagree with something specific, here are some quotes and links from this thread: Its not our softfork - its a softfork to enable a generic extension mechanism. We have no monopoly (and wouldnt want one) on use of the op code. Our only defence is meritocracy - if we build better, more secure sidechains and people prefer to use them. We wont be getting the fees off the sidechain either because those go to miners. If we have the technical edge and people use our stuff that seems sort of fair enough to me.
(and the rest of that post follow the link). Sidechains are not a proprietary technology. Everything is FOSS, open IP. [...]
Its not our softfork - its a softfork to enable a generic extension mechanism. We have no monopoly (and wouldnt want one) on use of the op code. Our only defence is meritocracy - if we build better, more secure sidechains and people prefer to use them. We wont be getting the fees off the sidechain either because those go to miners. If we have the technical edge and people use our stuff that seems sort of fair enough to me. [...]
Sidechains are just a mechanism to extend bitcoin. The interesting thing is the extension not the chain. If a better way to do it materialises great. If some sidechain innovations are so cool and well validated from $1b resting on them for a year that it allows bitcoin core to merge them fantastic. Actually Pieter Wuille views that as the best way to view the utility of sidechains, to enable longer and live validation of things that could then go into bitcoin where that'd be difficult to impossible to gain that confidence on directly.
There can also however be one-size fits-all limits. Some extensions are mutually incompatible, or too risky though interesting (eg snark contracts, zerocash) unless a way to contain the risk in chain is found. Also you can get some new scaling possibilities by having chains with different blocksizes. Its more decentralised and safer to have a small bitcoin main block and a medium sized sidechain block, than introduce a large main bitcoin block as there is an escape route and choice. You can within limits get your cake and eat it.
and Sidechains may also be good for that - an escape valve - people who want to do crazy stuff, can go do it in a sidechain, that no one (who cares about bitcoin ethos features) would use. Vs try to coerce legally or otherwise developers into subverting bitcoin itself at its core where there's no choice left, and bitcoin risks destruction.
and For conflict freedom to occur (and I think its an interesting and useful objective) bitcoin perhaps needs to be simplified and frozen, maybe moved to a formally provable specification rather than code as definition. Soft-forks could be prevented by consensus rule if we were convinced of perfect correctness.
Hard-forks are harder to foist on people because they require a near absolute majority whereas soft-forks are a bit more miner influenceable.
If we had an extension mechanism that doesnt touch core once setup, the core becomes that bit closer to freezable & formal specifiable refactor becoming possible. If we have the possibility for live-betas we are more likely to be able to get to formal specification as definition. (Thats a hard-fork for sure).
Another aspect of conflict freedom (other than freezing and forcing change to be hard-fork) is to enable permissionless innovation - then there's no conflict, people who want to try things can go try them without lobbying for changes to bitcoin. Also good.
and I think the bigger picture though is its premature - we have not yet released code, nor BIP draft for community discussion and picking apart and redesigning etc before there is something to merge mine. Its also useful (maybe you said it yourself also I think) for a federated peg to operate for a while in parallel with that open design discussion for people to see how it works. You can view the federated peg as a protocol adaptor - there can still be mining occuring on the sidechain with the federated peg, just the return peg is translated into a multisig for bitcoin by the federation servers.
After that if the community can settle on a op-code for extensibility everyone is happy with people including us can try to stand up a few sidechains. If no one likes them then they wont get mined. So as you can see sidechains and the op_spv really depend on community and economic majority approval, and thats a good thing.
and I dont think one can characterise the op_spv is to the disadvantage of blockstream competitors. Its an op code, anyone can use it to make sidechains or other things.
Other things: you can also use the op_spv opcode to enhance security and efficiency for SPV clients like smartphone wallets completely separately from sidechains. And to fast catchup headers also, the compact SPV proof is work-preserving.
If for example OpenTransactions sees a use for it, or ethereum wants to switch out ethers for bitcoin (i imagine the developers are attached to their premine for now) but perhaps Mastercoin or something thats market cap is falling, seeing less use and the ICO people probably mostly dumped by now (if thats a fair characterisation, dont follow it closely) maybe they might want to migrate to a sidechain, thats all expected and good. Permisionless innovation is the point of sidechains. You could even one-way peg the remaining mastercoins into a sidechain to allow their residual tradability.
If you mean it allows bitcoin to more easily incorporate features, well most alts dont really have features, or not meaningful or useful/non-broken ones, but there are some feature coins and bitcoin 2.0ish coins that do. I dont see how extending bitcoin is unfair - they're all leeching off and copying bitcoin, which was the actual innovation - why cant bitcoin take little bits of innovation back too?
and Another way to look at sidechains btw is that a federated peg is a multi-sig (with modest parameters eg 5 of 10 and some trustworthy security competent bitcoin interested businesses) and a SPV peg is a bigger federated peg with a 5000 of 10000 multisig with dynamic membership (ie whoever is mining the chain right now). The spv peg op_code is an opcode to understand those dynamic membership multisigs. The dynamic membership multi sigs (DMMS for short) are written about in the sidechain white paper http://www.blockstream.com/sidechains.pdf and are a different way to look at bitcoin mining, though its actually the same thing. You can also combine DMMS sigs with regular multisigs, its just an op code so you can program with it. eg IF ( 0.5*DMMS + 0.5*multisig(5,10) ) THEN spend coin. Or IF ( hashrate > 75% AND DMMS ) OR ( hashrate <= 75% AND multisig(5,10) ) THEN spend coin can react to hashrate drops. Different people could even use different peg rules on the same chain depending on their security tradoff preferences. I dont see that as some how evil or dangerous relating to offchain transactions (we've seen them cause system shocks mtgox etc) or federated pegs or voting pools (then you are depending on the 5 of 10 of their security etc its better but its still non-zero risk) ... its just the next evolution in that direction - more decentralised, more things enforced by the network. For example read Nick Szabo's recent blog post about fiduciary code http://unenumerated.blogspot.com/2014/12/the-dawn-of-trustworthy-computing.html what do you think he's talking about? Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
adam3us
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2015, 11:53:01 PM |
|
i mean, look, we have unencumbered BTC units traveling freely on an ultra secure blockchain whose value involves no counterparty and no other asset.
now, you're asking us to accept an unprecedented change to the protocol which will allow BTC units to intermingle with all sorts of assets limited only by our imaginations all while traveling on a less secure SC.
We havent actually proposed anything concrete yet, but we expect to with code and a BIP for a op code to do something that is nearly or maybe actually possible already just less efficiently. The alternative is offchain transactions which are impossible to stop, constitute probably 90% of bitcoin transactions, and remove fees from bitcoin network, and result in an ongoing economic impact when exchanges and other startups with custody of other peoples bitcoins get hacked, get "hacked" or steal them, get them frozen, deleted by accident etc. That seems like a step forward to me. Its an op_code. We dont "own" the op code. Anyone can use it to write any scripts they can cook up, to do with audit of sidechains or other users they may find. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 12:01:46 AM |
|
i have a suggestion, out of fairness sake. why don't we allow JR & ft, along with any other wanton altcoin/Bitcoin 2.0 dev, to insert their own highly specific op_code function into Bitcoin source code that benefits their own business model? as long as it's open source, it should be fine, right? and we shouldn't care if they are a for-profit, let alone nefarious, business; ppl can just ignore them.
There we go, thats the cypherpdoc we know actually, i'm quite serious. let me rephrase the exact same concept. we can let those guys insert an op_code of their choice which will be open source. it will therefore be usable by anyone and not owned by them. ppl will be free to ignore it by choice, therefore it can cause no harm. just like your spvp. why would you want to "prevent" them from doing that?
|
|
|
|
Odalv
Legendary
Offline
Activity: 1414
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 12:05:27 AM |
|
... we can let those guys insert an op_code ...
Do you know how many op_codes bitcoin already supports and what they do ? https://en.bitcoin.it/wiki/Script
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 12:10:49 AM |
|
nope. i'm just going along with BS's new way of presenting this argument. if we shouldn't prevent the spvp op_code, why should we prevent op_codes submitted by OT or any other alt or Bitcoin 2.0?
|
|
|
|
adam3us
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 12:17:14 AM |
|
i have a suggestion, out of fairness sake. why don't we allow JR & ft, along with any other wanton altcoin/Bitcoin 2.0 dev, to insert their own highly specific op_code function into Bitcoin source code that benefits their own business model? as long as it's open source, it should be fine, right? and we shouldn't care if they are a for-profit, let alone nefarious, business; ppl can just ignore them.
There we go, thats the cypherpdoc we know actually, i'm quite serious. let me rephrase the exact same concept. we can let those guys insert an op_code of their choice which will be open source. it will therefore be usable by anyone and not owned by them. ppl will be free to ignore it by choice, therefore it can cause no harm. just like your spvp. why would you want to "prevent" them from doing that? I wouldnt work to prevent it I'd evaluate whether it was a good idea or not. Same as anyone else involved with bitcoin development, so it depends on the value & risks. Wanna get specific? op_snark or op_weil-pair support so someone can implement zerocash right in bitcoin? What do you think? In or too risky? (I have a detailed rationale as ecash crypto is my thing, but I'll let you go first:) There is scarce development and QA bandwidth though, and risk from complexity. One advantage of sidechains is its a sort of meta-opcode - when you have it you can do nearly anything else, eg you can do op_snark without #including however many kloc of code for a snark library into bitcoind. As GMaxwell said when I expressed on #bitcoin-wizards right after he connected the dots between his previous snark based covenant idea/discussion and my one-way peg idea to explain two-way pegs, I said "but would that be practical to put into bitcoin given the whole point of pegs is to avoid needing to make changes" and his reply as "well maybe, because its the one change to rule them all". So I think meta-op_codes have any an extra argument going for them. (I didnt originally consider two-way pegs because I assumed that you need to find a way that doesnt involve changes, as the rate of pace of change due to risk is the problem I was trying to fix, one-way pegs can do somethings including live-betas but with higher risk of brown-out). one-way pegs explained here: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02944.htmlAdam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
Odalv
Legendary
Offline
Activity: 1414
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 12:18:35 AM |
|
nope. i'm just going along with BS's new way of presenting this argument. if we shouldn't prevent the spvp op_code, why should we prevent op_codes submitted by OT or any other alt or Bitcoin 2.0? It is possible to write LONG script. This script will be hard to understand by human. (it will even hard to understand by programmer) .. and we can replace this LONG UNREADABLE script with single opcode "op_spvproof_verify" => everybody can understand and see what that transaction means.
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 12:38:59 AM Last edit: January 02, 2015, 02:51:14 AM by cypherdoc |
|
both you guys are missing the point.
Adam, (& nullc over on Reddit) you have been expressing this conflict as me "preventing" you from giving Bitcoiners a choice to use an op_code that you believe will be helpful to us all. the tech doesn't matter with this line of reasoning as you've tried to turn this into an ethical or fairness issue under the principle of FOSS. fine.
by that same logic, you shouldn't prevent an alt or Bitcoin 2.0 that might want to do the same thing you want to do. as long as other devs are free to copy or utilize an alts op_code, then we should also allow its insertion into the Bitcoin source code alongside your spvp. it shouldn't hurt b/c Bitcoiners are free to ignore the implications as they can simply inspect the code for any bugs or malware.
or, as i suspect is what is going on here since you are a for-profit, your sense of fairness is selective.
|
|
|
|
BlindMayorBitcorn
Legendary
Offline
Activity: 1260
Merit: 1116
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 12:41:55 AM |
|
zing*
|
Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
|
|
|
tvbcof
Legendary
Offline
Activity: 4662
Merit: 1276
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 01:47:42 AM |
|
No. He said that EVERYTHING approaches zero profitability in a free market. Your hypothesis then is it's not worth doing anything in life because everything is worthless.
I was just trying to gauge where Justus's head was at. Sometime's it's hard to tell with his type. Adam says he's OK, but I'm not so sure. His response tells me that he's probably mostly just another pumper. Oh well...old stackers like the doc and I, if we are being honest with ourselves, recognize that we owe a lot to the pumpers and the 'principled Libertarian' shtick is hands-down the most effective in Bitcoinland for whatever reason. Justus rocks here. Hey J-man: You pump 'em and I'll dump 'em homey. The cool thing is that someone else is paying him at least enough to keep his pantry stocked with Top-Ramen, though with Monetas/Concentric/whatever it seems quite possible that it may be me in one of those 'your tax dollars at work' type of deals.
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
cbeast
Donator
Legendary
Offline
Activity: 1736
Merit: 1006
Let's talk governance, lipstick, and pigs.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 01:51:10 AM |
|
No. He said that EVERYTHING approaches zero profitability in a free market. Your hypothesis then is it's not worth doing anything in life because everything is worthless.
I was just trying to gauge where Justus's head was at. Sometime's it's hard to tell with his type. Adam says he's OK, but I'm not so sure. His response tells me that he's probably mostly just another pumper. Oh well...old stackers like the doc and I, if we are being honest with ourselves, recognize that we owe a lot to the pumpers and the 'principled Libertarian' shtick is hands-down the most effective in Bitcoinland for whatever reason. Justus rocks here. Hey J-man: You pump 'em and I'll dump 'em homey. The cool thing is that someone else is paying him at least enough to keep his pantry stocked with Top-Ramen, though with Monetas/Concentric/whatever it seems quite possible that it may be me in one of those 'your tax dollars at work' type of deals. I will vouch for Justus. I know him personally and we've had many discussions. He is a white hat. He is much younger than me and I don't agree with his politics, but every generation must make their own path.
|
Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 03:35:31 AM |
|
Bitcoins killer app is SOV.
If we allow an offramp from MC to SC's, I think that goes away.
|
|
|
|
cbeast
Donator
Legendary
Offline
Activity: 1736
Merit: 1006
Let's talk governance, lipstick, and pigs.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 03:46:08 AM |
|
Bitcoins killer app is SOV.
If we allow an offramp from MC to SC's, I think that goes away.
I think the whole SC thing is a red herring. If they can't do it without "social structures" then it's not Bitcoin. OTOH, the social structure crowd has plenty of space for developing mining pool "social structures" that incentives decentralization through Delegated 'insert-term-here' technology.
|
Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 04:07:17 AM |
|
Bitcoins killer app is SOV.
If we allow an offramp from MC to SC's, I think that goes away.
I think the whole SC thing is a red herring. If they can't do it without "social structures" then it's not Bitcoin. OTOH, the social structure crowd has plenty of space for developing mining pool "social structures" that incentives decentralization through Delegated 'insert-term-here' technology. I think you mean Trojan Horse. Someone is going to lose alot of money. In fact, most people investing in cryptocurrencies are going to lose money. That's how bull markets are.
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2015, 04:14:06 AM |
|
Bitcoins killer app is SOV.
If we allow an offramp from MC to SC's, I think that goes away.
I think the whole SC thing is a red herring. If they can't do it without "social structures" then it's not Bitcoin. OTOH, the social structure crowd has plenty of space for developing mining pool "social structures" that incentives decentralization through Delegated 'insert-term-here' technology. I think you mean Trojan Horse. Someone is going to lose alot of money. In fact, most people investing in cryptocurrencies are going to lose money. That's how bull markets are. i mean, we can't bring everyone with us. it wouldn't be fair.
|
|
|
|
|