sockpuppet1
Newbie
 Offline
Activity: 28
Merit: 0
|
 |
May 15, 2016, 06:06:12 PM |
|
"Anonymity well I tried"
Maybe anonmity is not that important for your average user. But, the ability to keep what is yours from being taken by thebanksters, TPTB, your local hacker, is an absolute. The unconditional control of any CC must remain with the individual.
Mass privacy is very important. That is why Monero and Zcash matter. We'll never have mass anonymity. Fuhgeddaboudit. Privacy doesn't mean privacy from the authorities. Sorry. Politics and technology will never allow it. I tried to search for the absolute technology for anonymity and I can promise you it does not exist to be found. I promise you. The control over an individual's CC will remain with the individual, but the control over the CC protocol will remain with the global elite. This will always be the case. Accept it. This is the reality of the world we exist in. You say the protocol will remain with the global elite ... will that include your version of a CC, should it ever come to fruition? If I bring my design to fruition, the intent is that it can't be centralized, because the power remains in the hands of the each spender to choose where they sent their unprofitable PoW share. But the bottom line is that Iron Law of Political Economics guarantees that in effect the global elite control the minds of the people, e.g. which wallet software the spenders choose, etc.. You'll never create a protocol that is immune to political economics. Not even the base protocols of the Internet are immune. But yeah, I'd attempt to give us the best that can be achieved in terms of decentralization. I am just being honest. I don't want to fool people with ideological bullshit. |
|
|
|
|
|
|
|
|
|
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
|
sockpuppet1
Newbie
Offline
Activity: 28
Merit: 0
|
|
May 15, 2016, 06:56:51 PM |
|
I was thinking earlier about the legal system vs crypto. Does anyone think user defined mixing will be a weakpoint of Monero in the legal department? As in, a fixed mixed count would have been preferable if attempting to design around the law when user defined is pretty similar to active mixing. It seems kind of obvious that governments would be far more likely to consider active mixing as an act of laundering (darkcoin), while if anonymity is part of the protocol itself, it's just a shortcoming of government auditing. Both Monero and Zcash are safer legal-wise (than Darkcoin), although you would likely have to enforce a fixed mix count instead of variable if you really wanted to be safe in Monero.
I believe perhaps the global elite will kill off any system which doesn't mandate a viewkey on each mixed transaction, wherein some elected foundation or body is given responsibility for whom has the private key(s) to the viewkey. Better perhaps a multisig viewkey would be best where these would be given to multiple authorities (e.g. each of the major powers or regions national security agencies), and then a quorum of them would have to agree in order to view a transaction. Thus I think the level of mixing (above 0) is irrelevant. I just don't believe you snub the global elite and expect to not get your ass wiped in the mud. I had hoped for an absolute technological immunity, but I studied all the technology deeply and I am very, very confident to tell you that it is impossible. The global elite will remain in control of the Iron Law of Political Economics. Mass privacy is very important and Monero should stop being delusional and realize how they have to structure their system in order to be accepted. I guess they might just attack the users and catch them at the on/off ramps and destroy interest in coins that obscure the blockchain from the authorities. |
|
|
|
|
|
TechorMarketing
|
I guess they might just attack the users and catch them at the on/off ramps and destroy interest in coins that obscure the blockchain from the authorities.
Even if one country makes using a currency illegal it will remain legal in many other places. There is no way all on/off ramps can be controlled. How can a user living in a country where use of cryptocurrencies are unregulated be controlled? With the rise of decentralized exchanges, controlling all on and off ramps seems impossible. Some countries may choose to be welcoming instead of hostile. |
|
|
|
|
sockpuppet1
Newbie
Offline
Activity: 28
Merit: 0
|
|
May 15, 2016, 07:19:28 PM
Last edit: May 15, 2016, 07:52:41 PM by sockpuppet1 |
|
How can a user living in a country where use of cryptocurrencies are unregulated be controlled?
There will exist no such place. Name one. Just one. Moreover, the protocol is controlled by the Chinese mining cartel, so all the regulation can be done from China. Your coins can be confiscated China regulates their ASIC mining farms. If Monero scales up, it will also be captured by the Chinese cartel. With the rise of decentralized exchanges, controlling all on and off ramps seems impossible. Some countries may choose to be welcoming instead of hostile.
The Internet will be regulated. China is the model. They will assume the throne of the financial capital of the world in 2033. You can waste your time disbelieving (and end up in jail and/or all you wealth confiscated). Meanwhile I will get my ducks aligned so I am congruent with the reality. |
|
|
|
|
sockpuppet1
Newbie
Offline
Activity: 28
Merit: 0
|
|
May 16, 2016, 06:09:12 AM
Last edit: May 16, 2016, 06:23:52 AM by sockpuppet1 |
|
What's Monero's problem? None at all really, there are just a lot of shitcoin scammers and their sock puppets (most of the posts on this thread probably, and the other one run by one of those scammers where my replies are selectively deleted) who hate us, and that's a sign we're doing something right.
No smooth there is another problem. Monero has this attitude that they are the shit and every one else is shit. And your community disrespects those who have supported Monero. I took so much abuse from Shen-noether, iCEBREAKER, and various other members of your community. Now it is time for payback. Do you really think I would post that I have a technical solution to eliminate the simultaneity in CoinJoin if I don't. Sheesh. You need to teach your community that I am legit. I am really disappointed with your shit community. So now I am shopping around for someone who can take my technical idea and make it a Monero-killer asap. So I can teach your community a lesson that they deserve.
Step 1) Open a short position in XMR
Step 2) Come to speculation thread and get "mad" about something
Step 3) Tell everyone you found an exploit/breakthrough/whatever and XMR is about to be "REKT"
Step 4) Profit
Sound familiar?
I have no speculative position in cyrpto-currency. I have not consulted with anyone else on this technological idea who does have a speculative position on Monero or Dash, other than what I have communicated here to all of you thus all of you with equal opportunity to speculate on what I wrote. I am not here in CC to play silly games. I don't speculate in CC. I work on technology. That is all I do. Day in an day out. I had my head deep in creating a new programming language and I stopped suddenly because an idea popped into my head. Then I realized I had a mistake it wasn't fully formed, so I deleted the post I had made about it. Then noobtrader attacked my reputation with his snide quote of a post I deleted within 60 seconds of posting it. So then later the next day, I thought about it again for a another minute or two, and I realized I could actually make it fully formed and prevent all the trust in the system in terms of making sure that no party can steal funds and that no party can jam the protocol. So then I realized I had stumbled onto a way to remove the simultaneity requirement (and jamming problem) that plagues CoinJoin. I got excited. I posted about it again here and specifically to take revenge on noobtrader for disrespecting me and being a jerk. And so what I have received so far is more of the same shit attitude from the Monero community. Now you guys will learn that I am legit. I have no idea why you think I am not legit. If you even took the time to understand my technical research over the past 3 years, you'd realize I had made major technical insights. Whatever! Fuck. ...something that can best be described as a hybrid between Monero and Dash.
Not really. I removed the simultaneity requirement in CoinJoin. Since when has CoinJoin been similar to Cryptonote. |
|
|
|
|
sockpuppet1
Newbie
Offline
Activity: 28
Merit: 0
|
|
May 16, 2016, 07:18:16 AM |
|
I do not care much what it is you are trying to hype this time.
My point is just that you persist in the hawking, and do nothing. If you continue doing this, you will end up frustrated and angry, and without having helped humanity.
A proof allows others to build upon, find flaws, and better what you are working on, so you can in turn find flaws, and better it. This is the whole point of free software. We stand on the shoulders of giants. I invite you to try to do so as well. I think everyone would gain from it.
This lies at the heart as to why proprietary software development and DRM are doomed to fail. I have an Idea and I want to sell it, so I must keep it a secret and add lots of DRM to prevent anyone else from evaluating and vetting the idea, because someone else might copy it. Furthermore I then turn everyday devices in Orwellian surveillance tools and lobby the state to make a criminal offense to circumvent the DRM and gain control the devices one owns. Of course all the secrets and DRM only attempt to prevent anyone from finding out if the idea even works, or even if the idea puts the health and life of innocent people at risk. So yourself coming from academia (a professor or physics researcher in Canada) where you are paid by socialism to do your profession, your vision of how work gets done is we all have a job paid for by the government and there is no proprietary intellectual property any more. This is a Communist delusion and it always ends in megadeath due to economic collapse. The Socialists were in control the Weimar Republic that lead to Hitler's rise. There are so many examples that litter the history of mankind. Btw, I never advocated that my idea wouldn't be open sourced. I posited that it would be better for an altcoin to implement my idea and then later announce it for peer review when they were very close to launching it, so they would have first mover advantage. Besides there isn't really much need for peer review on the idea, because I am already so expert on anonymity technology that I am the person who should be peer reviewing it. If I can get some compensation in return for the 4 years of day in and day out technical research effort I have devoted to crypto-currency, then that is capitalism. We all know that the altcoin arena is a gambler's paradise and that is all that it is. You Monero folks seem to think you are holier than thou, but even your own community is only here because they want to make money from speculation. Please stop with the ideological dogma. Admit reality. Open source is not Communism, because no one forces anyone to do anything. But viral copy-left free software licenses that forces those who contribute to open source to not be able to create proprietary derivative works, is in fact Communism. It purports to create a world where everything is non-profit. Eric Raymond, Linus Torvalds, and other non-insane people prefer permissive open source licences. I prefer the Unlicense which allows anyone to do what ever they want with my code. They don't even need to attribute me! Let me give you an example so this isn't all just abstract. Here is the open source: https://www.nativescript.org/Here is the for-profit derivative work by the same people (and that doesn't mean they open source all their server code): http://www.telerik.com/platform/appbuilderYou are a guy who would say that musicians can't charge money for their downloads. And you advocate illegal decentralized file sharing systems wherein it is impossible to for the copyright holder to have the illegal content removed. You want to create a society of theft, which is precisely what Socialism is. There is no need to enforce DRM in order to have people pay for songs. I will show you how to do it when I launch JAMBOX, which will be an open sourced decentralized platform. But it won't support having people standup file server nodes on their home Internet connections as a way to subvert copyright law. You Commies are entirely out-of-touch with where the prosperity is going to come from in the fledging Knowledge Digital Information Age. I am going to continually kick your ass in the market and in technology, because I have 30 years experience doing that successfully. And because I am a capitalist. Smooth has affiliated with the wrong crowd. Hopefully he will wise up eventually as he sees that Monero is stuck in the mud and everyone else is steaming ahead. Look Ethereum and Dash have both already moved a lot more money through their ecosystems than Monero. That doesn't mean I endorse concentrated distribution wherein the insiders can manipulate the float/market cap/price nor the preselling of vaporware, and I personally wouldn't do especially the ICO aspect because I think it is very illegal for me to do that because I am an expat US citizen. But that is the reality of the altcoin ecosystem. Everyone is here to gamble. The market gives what is demanded. Period. We can complain until we are blue in the face, but it will not remove the market demand for P&D. Eventually the SEC will crackdown (perhaps this DAO thing) but for now they are letting it run wild. So instead of dogma, it behoves each person to deal with the reality of the situation. Which is what I am doing. I personally am not going to launch an ICO. But if someone wants to pay me for my technical work, then why should I withhold my work from the marketplace. You guys are so braggart, yet you can't even afford to fund your developers to work full time. Lately I had recognized that there are individuals such as fluffypony that worked very hard on Monero and that Monero has perhaps the best distribution of any altcoin. So I had become more supportive of Monero, in spite of the fact that some members of the Monero community remain abusive to me. I still have a very bad taste in mouth from the Reddit discussions I had with your condescending jerk cryptographer Shen-noether last year. If your community simply respected others, then they (at least I) could respect you. But you disrespect the work of others. And that really pisses me off. I do think it is important to inform speculators and the coin developers/controlling entities about the securities laws. I do think virtuall all altcoins are some sort of "mine the speculators" model. But lately I've realized that it is not my job to tell the marketplace it is wrong. The marketplace is what it is. This is nature doing its thing. I would be a Communist if I tried to tell nature it is wrong. The SEC might end up cracking down at some point, and that will be nature doing its thing. Yes I believe in open source (not free software because nothing is free!) and I believe in creating a profitable corporation in order to fund the open source. This is what Eric Raymond understood and why he targeted his marketing to the Fortune 500 and he revolutionized the open source paradigm from a failure lead by Richard Stallman, to a successful paradigm adopted by mainstream capitalist society and business. ArticMine, I don't dislike you as a person, but frankly you smoked too much pot up there in Canada. Intellectual property is the battleground of the 21st century. One can attempt to protect "Intellectual Property" and be on the side of tyranny or one can choose freedom. Great videos. Eric S. Raymond and Linus Torvalds make very good cases for Free LIbre Open Source Software and actually complement Richard M. Stallman's views. Different opinions with fundamentally similar objectives are actually a strength not a weakness. Edit: Eventually the truth will come out as happened in the case of Volkswagen. Unfortunately many people in Europe had a premature death because of Volkswagen's proprietary software and DRM. |
|
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 11:35:04 AM |
|
So now I am shopping around for someone who can take my technical idea and make it a Monero-killer asap. So I can teach your community a lesson that they deserve.
I don't think any coin has a distinct 'community' as such, and there aren't tribes ready to go to war with each other. I like monero, and about 20 other decent alts, and btc off course too, so I'm in all of those 'communities, and when you launch your own JAMBOX I'll probably support that, so I'll be part of your community too. Don't get me wrong, some or even several of those in the Monero community I consider to be my friends. For example, generalizethis and I have gotten along very well lately, but that perhaps has only been since I was writing in support of Monero and against "shitcoins" lately. Note please see my prior message wherein I explained that my attitude towards "shitcoins" has matured. Monero has a community that attacks and belittles anyone who claims to have any technical innovation. How does that help us advance the state-of-the-art? Their cryptographer Shen-noether was very arrogant and condescending to me when I offered to discuss their RingCT design because I had also independently designed ZKT before they did and mine used the CCT instead of CT. They were very offended that anyone else could have possibly designed something before they did. Just the other day I posted in Monero's thread to let them know I had a new technical discovery and they ridicule me. So yes I think revenge is appropriate. The appropriate revenge is proving them wrong by releasing a coin with my new technology. I think most crypto followers are interested in lots of coins, so if your motivation is to teach the monero community a lesson I think you'll just push people away from your project. I love football, but I don't like hooligans who use it as an excuse to fight. I want to see a great match. It's the same here; if your project is cool people will support it, and it can co-exist with monero and lots of other coins. But if you're motivated by 'revenge' you'll ultimately fail IMO
I want to teach those who ridicule me that they only motivate me to compete against them, rather than to join and help them. I tried to be helpful with them several times, and they can only perceive it negatively. I really don't understand their community. Most acrimonious community I've ever come across. They insult each other daily in the Monero Speculation thread talking about useless crap that doesn't matter. They need Smooth to act as a dictator to censor posts just to keep them from not turning the thread into a continuous flame war. Followers can be interested in lots of coins, but ultimately they choose the one that can earn them the most money and the one with the best technology. |
|
|
|
fluffypony
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
May 16, 2016, 11:41:27 AM |
|
The appropriate revenge is proving them wrong by releasing a coin with my new technology.
by releasing a coin with my new technology
by releasing a coin
by releasing
releasing
What a time to be alive! |
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 12:10:04 PM
Last edit: May 16, 2016, 12:22:22 PM by TPTB_need_war |
|
What is Monero's Problem? Some of the monero most prominent members act like bullies in the Bitcointalk forums. And that's a shame. No, criticizing bad tech is criticizing bad tech and coins built on (you guessed it) bad tech don't like when you point out their bad tech--though I think vcashers are mad because they borrowed code from Satoshi and forgot to thank him/her/them. I have no problem with threads that want to discuss the technology of various coins, and/or to discuss the fairness of the distribution and speculation ecosystem of a coin. You know I have enjoined and even lead some of those discussions, believing that I was justified to point that shoddy technology was being hyped as more than it really is, and/or that false market caps are being created by insiders buying from themselves. But I also realized when to let it go. It is clear to me after watching the ETH bubble burst then reignite and the DAO bubble underway, and Lisk, Iota, etc.. that the speculators here want this. Who are you and I to dominate the entire forum telling them all to stop gambling? That is their right. We warned the developers about potential incrimination. What more should we do? I decided to stop wasting my time trying to tame the Wild West. Much better to find myself a bull to ride and let the SEC do its job when it wants to. What is ironic after all, is Monero and Zcash may not have the best anonymity technology. I have a surprise coming. I even surprised myself. And I also surprised my secret co-developer. Yes you all didn't know I have a secret co-developer. I prefer to let people underestimate me. All this time you all thought I was working alone. Hahaha. You'd think they would be going after dash's market cap as they are in the same quick transaction market, but they also went after Bitcoin, so maybe they have a thing about attacking coins that are doing it the right way, which doesn't make sense, since strategically it would make more sense to go after the coin with similar investor profile or after a less technically proficient user base that can be more easily swayed by FUD--but whatever.... I'm sure they think they know what they're doing  Vcash's Zerotime can't scale to 100,000 txns/sec. My issue with Vcash is John doesn't publish all the specifics. He doesn't want us to peer review his technology. And thus we can safely assume the technology has weaknesses he doesn't want us to see. Because there is already a pattern of weaknesses. Zerotime can't scale well but he never points that out. And it is also theoretically susceptible to a Sybil attack although that attack won't happen while the network is well controlled by insiders. But if speculators want to invest in Vcash, then I am not going to tell them what to do. Maybe John will surprise us all. The speculators have their own decision and can speculate and promote what ever they want. |
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 12:10:46 PM
Last edit: May 16, 2016, 12:23:35 PM by TPTB_need_war |
|
The appropriate revenge is proving them wrong by releasing a coin with my new technology.
by releasing a coin with my new technology
by releasing a coin
by releasing
releasing
What a time to be alive! fluffypony I don't have acrimony against you. But some of the individuals in your community are abusive. You are also being defensive here with this sort of response. Remember I didn't go into your thread wanting to create a new coin. I just was mentioning that I think I had discovered something new. It was just a tangential thing, as I was busy on other work on creating a programming language. I didn't expect to do anything much with it, perhaps sell it to Dash for a small token amount. But your community pissed me off so much with their ridicule, that I became more determined to make sure my idea would be released asap in a serious coin that can compete against Monero. So now you a have bigger problem coming. Thanks to your community's abusive behavior. I have a right to develop technology and not release. Many, many researchers do such things. Are you invalidating the value of research. Come on don't be so condescending towards me. I had been writing positively and supportively of your work and effort. Unfortunately it is the tendency of some of your community members to be abusive that creates animosity. You may see a release in approximately 1 month. I am discussions right now with my co-developer. We may have an announcement as early as tomorrow. We are still nailing down the issues. I just discovered this new technology breakthrough in the past 24 hours. I need a bit more time to make sure it is correct. But so far, my co-developer and I both already think it is correct. Note when I write "co-developer" I actually mean that someone I collaborate with on ideas and who is independent of me. And if this this new plan proceeds, I will just be the contract programmer and the technical lead, but not the entity who is launching the coin. Any way, more details to follow once discussions are completed. P.S. we are thinking of forking Bitcoin 0.12 and making the modifications for anonymity on that. And then we will add the advances I want for my ultimate coin in stages. |
|
|
|
arielbit
Legendary
Offline
Activity: 3416
Merit: 1059
|
|
May 16, 2016, 12:43:15 PM |
|
bitcoin fork...minable? i have my cards ready here...newly thermal pasted  |
|
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 12:50:16 PM |
|
So now I am shopping around for someone who can take my technical idea and make it a Monero-killer asap. So I can teach your community a lesson that they deserve.
I don't think any coin has a distinct 'community' as such, and there aren't tribes ready to go to war with each other. I like monero, and about 20 other decent alts, and btc off course too, so I'm in all of those 'communities, and when you launch your own JAMBOX I'll probably support that, so I'll be part of your community too. Don't get me wrong, some or even several of those in the Monero community I consider to be my friends. For example, generalizethis and I have gotten along very well lately, but that perhaps has only been since I was writing in support of Monero and against shitcoins lately. I will continue to be supportive in your efforts wherever they lead--though why they're leading to a coin built like an oligarchy is beyond me. There's no way I can support dash's centralized design, but if you fix their privacy issues, good--at least people buying the coin for privacy won't be getting ripped off in that department. Whatever happened between you and Shen is between the two of you, but I respect both of you and hope it isn't a permanent rift as talent is tough to find in this community and both of you have that in spades. What happened between Shen and I can never be patched up. Same as the relationship between Gmaxwell and I can never be patched up. I saw already the way they treat others. People don't change. Yeah I will tell someone they are an idiot, but only after giving them many chances to not be. I try my best to give people a fair shake. Whereas, Shen and Gmax disrespect people who are obviously not idiots. I don't even disrespect people who frustrate me with their inability to comprehend. I just get frustrated because I am only one man and I can't write 3000 posts per day to cure everyone's misconceptions. The solution to that was letting go. Just stop trying to communicate to everyone. Just pick my spots to communicate more selectively. As for those who habitually look down on others and not even giving them a fair shake, well they earn my ire and burn the flame inside me white hot. I really hate people who can't appreciate others as human beings. Everyone deserves the benefit-of-the-doubt and a fair hearing. It is so ironic actually. It may end up that masternodes are a superior solution for scaling anonymity to the masses than Monero's on chain ring sigs or Zcash's zk-snarks. Note I didn't say masternodes for mining nor for governance (nor oligarchy controlled from an instamine). Rather for a specific feature of scaling anonymity. And then we get very performant DEX (decentralized exchange) out of that new design as well. It actually surprised me. I was thinking on chain anonymity was the holy grail. But the problem set paradigm shifted. Here are the potential advantages my co-developer and I quickly enumerated today in chat: Co-dev: "so ours is less bloat, prunable, more anonymous, quantum-computing resistant, more performant, and IP shielding" myself: "and our anonymity sets are huge, potentially 1000s per mix" Note that ours will have the weakness compared to RingCT/Zcash that we won't hide values so the mixing will be limited to transactions that people choose to mix with specific denominations (which is the way the current Monero works). I don't think we plan to mix every single transaction and have a complex wallet like Monero. Monero will simplify that when they implement RingCT. But RingCT can never scale to every (micro) transactions of the masses. Any way I am talking off the top of my head and too prematurely. I need to go write some of these specs down. TPTB_need_war have you thought about working at or consulting for some existing project in the crypto sphere rather than creating your own? You seem to be able to criticize anything and everything constructively. That's an amazing asset.
If we proceed to launch a new coin, then I will be joining an existing crypto sphere. My co-developer is prolific, already has a crypto community, already has an anonymous coin, and you will all recognize his name. I am not doing this alone. However there will be a twist. I will explain maybe tomorrow. |
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 01:38:44 PM |
|
I can say that my co-developer refused to allow the masternodes have the ability to unmask the anonymity. I was arguing for a simpler design but his standards of ethics on the technology are even higher than mine. Then apparently we were able to devise a solution so the masternode could not unmask.
I was arguing that the user could just mix numerous times, so even if the masternode could unmask one of the mixes, all the masternodes would need to collude to unmask numerous mixes. But my co-dev pushed for us to find an even greater assurance that the masternode can't unmask the anonymity. And we figured out how to do it.
I will excerpt what he and I wrote me in chat:
me: CoinShuffle does not scale.
me: CoinShuffle has a simultaniety requirement. Any one participant can jam it.
me: If you adopt CoinShuffle that is a death wish for the coin.
me: The coin will be jammed, nobody can use it, the coin will die.
me: Unless you make jamming costly, the adversaries will jam every CoinShuffle mix.
me: Afair, CoinShuffle requires forwarding each stage of the shuffle to the next participant. How do you distinguish between Internet connectivity failure and intentional jamming?
me: so then you can't confiscate a deposit if there is jamming
me: 1000 masternodes are guaranteed to be bought by the evil side?
me: We just need to decentralize mining more. My design is the spenders are the miners!
co-dev: i dont want to claim something is anonymous when a breach of data center compromises privacy
me: Dash has no problem with that. lol
co-dev: so that is why I say sparsely used massive number of virtual dcnets
me: I am not going to endorse anything using CoinShuffles and DCnets. I am fairly sure it will blow up.
me: I won't risk my reputation on such an experiment.
co-dev: i dont see why the submission to the masternode cant be protected in some way
me: I want a clean design that even if not perfect, we can be sure how it will work.
...(discussion of the solution)...
me: So the user can send their output to any masternode. So no one masternode sees all.
me: Okay great!!!!!!!!
...
me: Oh this is good.
...
me: I really like it. It is quantum computing resistant!
me: We can actually make this quantum resistant with lamport signatures. I already have the C code for lamport signatures on my github.
Edit: let me add that I know the logic from Monero and Zcash will be that masternodes can be monopolized by the NSA or other super power adversary. But remember there is no anonymity against such adversaries even with Monero and Zcash (due to meta data correlation). That is a delusion. The real market is bringing privacy to the masses. Which means you need scaling.
|
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 01:43:31 PM |
|
awe come on, don't tease
Give us a month (or two so we can launch) please before spilling all the technological beans. I don't know how long it will take to launch. S/w development always takes longer than estimated. Also I am not 100% sure yet if we are proceeding. I am still reviewing all these details. |
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 07:12:30 PM
Last edit: May 16, 2016, 08:39:12 PM by TPTB_need_war |
|
Another major advance for programming language design from me! I am starting to fire on all of my cylinders as I used to do when I was prolific. Damn illness the past 4 years held me back. I am feeling pretty good. I need to backup this info some where, in case every Rust forum private threads disappear. So I am putting this here so others can read about my design progress. I think we should first enumerate the cases where anonymous (as opposed to nominal enum and nominal trait A: B + C) unions and intersections would be useful to eliminate boilerplate and enable expression, before discussing whether and how to integrate them. 1. Intersections on nominal trait bounds. Rust already has this. 2. Unions of nominal data/function types and/or type parameters for function arguments and result types. 3. Unions for data/function types for the element type of first-class heterogeneous collections (avoids the alternative HList-style boilerplate and conflation of semantics). Subtyping subsumption or trait bound subsumption are not extensible in both directions of the Expression Problem. 4. Unions as the locally (not principle typings) inferred type of an expression, e.g. an if-else. Otherwise all branches of a code block must have the same type or we must employ the boilerplate of a nominal enum (which obviously can't be inferred). Can you think of any other use cases? Especially any for intersections? We do not want intersections of data/function types because that puts the anonymity on the outside of the type, i.e. it is no longer a data/function type and thus we introduce structural typing! Intersections of trait bounds can only be written on type parameters. Rust matches closure functions on structure, but the structure is always on the inside of a nominal trait bound. We don't want to introduce structural typing because it causes inference divergence and perhaps also unsoundness. My current thinking is that you can simply leave intersection and union types out of inference, so all inferred types are monomorphic, that way the type inference can look like HM.
Exactly my thought too as evident by my prior post wherein I think I enumerated all the use cases for first-class unions and intersections and they are all explicit annotations and/or local expression inference that is constrained by the annotated function signatures, so no need to involve first-class unions and intersections in principle typings inference. The question then would be how to introduce them. You could have first-class-polymorphism and introduce them in a datatype.
I am not thinking this is necessary, but if you can show an example where it can only be sound that way, I am interested to see it. Really type-annotation is necessary. We can stick to the 'only infer HM' types rule, and then it would be up to the programmer to annotate as appropriate.
Yes that is what I have always been thinking I wanted. The inference would only be for the expressions within the function body. I just don't see global inference as desireable. I understand there are some cases where local expressions require annotations due to failure of inference, but that failure will be less like with first unions. For example, in that Scala example that required needless type annotation of casting a None to Option[Int], the Option would not be a nominal type in my proposed language. Instead the type would be Int \/ (). So thus combining an Int and () in the same expression would produce an Int \/ () inferred type. To keep it simple, I probably would not have traits as well, nor would i have structs and enums, as these can all be constructed from intersection types.
I have explained that we need nominal types as that is how we differentiate from the structural types, so the structural types are never inferred as principle typings (instead only function signature annotations or as intra-function body expression types). I am trying to basically have Rust but with unions, GC, and async runtime. Will be a better Rust for high-level programming. Then I'd like to explore our mutual idea for minimizing the need to use GC for temporary objects lifetimes correlated with the program stack. 1. I've just glanced at your cited references and of course reminded that System F isn't generally decidable for principle typings inference. If I understand correctly, all your concerns with first-class unions and intersections is due to the need to have principle typings inference. If we annotate all free standing function declarations (lambdas in function argument expressions excepted), then the concern would be vanquished. Correct?
2. You are concerned that function annotations could become very noisy because for example intersections of trait bounds could become quite large. For example, a function needs certain trait bounds for the operations it performs in the function body, plus it needs to require all the trait bounds for any functions it calls. I have an idea for a solution to this if we (or I) were to decide to abandon principle typings inference. We could have each function only declare the trait bounds that it needs in its function body, and the additional trait bounds required by functions called within the function body, would be inferred onto the calling function's trait bounds. Since those called functions explicitly declare their trait bounds, then this is decidable. It is a tree structure.
3. Afaics, the ability to exclude certain traits is inherent in my complete solution to the Expression Problem, because the dictionaries are supplied to the function orthogonal to the objects that contain the data types; thus it is impossible to cast a polymorphic data type downstream to any trait bound that wasn't annotated on the function declaration. Thus to specify NoIORead, then simply don't add a IORead trait bound to the function. But you wanted to infer the function's types, because of #2 above. Apparently one of the reasons you think the intersection of types would be so large, is because you want to infer the fully generality of the principle typings, thus you allow for a larger set than the function even desires, e.g. if the append method is employed within the function, you would infer any trait bounds with any append method. But this seems to dangerous. I prefer for the programmer to be explicit about his semantics. So if the programmer must constrain the append method, then he might as well just write that constraint as a trait bound annotation on the function signature. So really I am failing to see the benefit of principle typings inference?
4. The interaction of HRT (and I presume HKT) with first class intersections and unions complicates principle typings inference, and likely makes it undecidable if not just incredibly complicated. Another reason to abandon principle typings inference, because first-class unions and intersections are essential from my perspective in order to make the code more elegant and less boilerplate.
One of my other goals is to make the compiler as fast and as simple as possible. So not having complex inference unification solvers would be advantage. I am thinking also there is a better chance of not having corner cases in the type system and bugs in the compiler.
These points were made upthread and I am thinking they still apply. Btw, you mentioned Ceylon but it doesn't have type classes. Afaik, HRT (higher-ranked types) are necessary when we need to input a polymorphic function, then resolve the function application polymorphism within the function body, i.e. not monomorphic. Instead we enumerated other solutions which are monomorphic:
1. Making that polymorphic function a method of nominal trait Foo and inputting Foo.
2. Or inputting a separate function for each polymorphic variant of application in the function body.
3. Or inputting a function employing unions for the variants, when the semantics are acceptable.
Afaik, HKT (higher-kinded types) are necessary when we need to abstract over the type constructor of ourself (speaking from the perspective of a data type). So for example, Self is a HKT when it is an result type in a trait, because this means any application of that trait requires to know which data type implemented that trait. We can see this more clearly in Scala, where we would write: trait Foo[Self <: Foo[Self]] {
def myself: Self = this;
}
class Bar extends Foo[Bar];
We can see that Self is abstracted over the construction of a type instance of Foo by the class ... extends, which is sort of analogous (not really) to an imp ... : in Rust. I don't see how HKT breaks monomorphism? I think the unsoundness in the interaction with unions or intersections would only be occurred if we try to put them in the declaration of the definition of a HKT: trait Foo[A, Self /\ A <: Foo[Self]] {
def myself: Self = this;
}
class Bar extends Foo[Int, Bar];
But can't even see the use cases where that capability would be useful. Do you? I am thinking of only allowing HKT on Self. |
|
|
|
|
TPTB_need_war (OP)
|
|
May 16, 2016, 10:01:59 PM |
|
Follow-up: Its no good knowing the types that 'may' be in the collection, when I read the head of the list what can I do with it?
Perhaps I need to expand that? If I don't know whether the element at the head of the list is a String or an Int I cannot do anything with the value.
That is true even if you use a nominal enum, a trait object, or even your HList. There is no way to avoid branching in software unless you only have one type () (unit) in the entire program. Effectively you are arguing you don't want a program. You want a brick. Even though there might be more than one data type of the trait bound dictionary, it can be possible to optimize this selection by for example keeping branches nearby in instruction cache and pipelines. What I am saying is an optimizing compiler can receive these dictionaries at compile-time so it can fiddle with them to optimize the branching performance. Rather than having them in some vtable that entirely breaks pipelining. There is nothing you can do to avoid branching. It is part of software. Sorry can't help you there. Lol. Any way thanks for the point. You indeed drove this issue straight to the point which is why I really appreciate you. I couldn't have seen those issues immediately without you raising the issue. Btw, I just realized that we could actually count the number of each data type in the collection using typing and then compiler would know which cases are likely to occur most often. Or a hotspot VM can attempt these profiling low-level optimizations with run-time profiling. If I know all elements in the collection implement the X trait, then I know I can call any method of the X trait on the value of unknown type safely.
I can do that because I know that all elements in the collection must implement trait X, because I know the memory layout of the vtable for trait X, and I can then indirect function call to the vtable to access the method no matter what the type is at the head of the list.
Knowing which trait implementations are possible not just which trait bounds, can enable optimizations as I mentioned above. If you can't limit which trait implementations, you can't make the above optimizations and you'll be stuck with indirecting to a vtable and stalling the CPU pipeline. So the important thing is to know what traits all elements in the collection must implement, I don't care about their types, and I cannot know their types at runtime. knowing that the collection is Int \/ String does not help me do anything with the value at the list head, because I don't know if that particular value is a String or an Int .
Incorrect as explained above. All my performance work is based on benchmarking and profiling. Unfortunately not all algorithms parallelise well. One of my monte-carlo simulations gains so much information from a single run, anything in parallel is useless (because you now have much better parameters, all your parallel runs are no longer relevant).
Okay that is I guess true in some or even many cases. But I think for most what I would refer to as "mobile apps" and server apps (which is my first use case) that concurrency is vital. Parallelism also maybe to some degree. Afaik, HKT are necessary when we need to abstract over the type constructor of ourself (speaking from the perspective of a data type). So for example, Self is a HKT when it is an result type in a trait, because this means any application of that trait requires to know which data type implemented that trait. We can see this more clearly in Scala, where we would write: trait Foo[Self <: Foo[Self]] {
def myself: Self = this;
}
class Bar extends Foo[Bar];
I am not sure that the Scala is saying? The type parameter of Foo must be a subtype of Foo with the parameter Self? It doesn't really make sense to me. Yes it is saying that Foo[Self] takes a parameter Self. Then it also constrains the parameter Self to be a subtype of Foo[Self]. So then means that Self must extends Foo[Self]. So this makes Self a HKT because it is a type parameter that over the type instance construction operator of Foo. When we declare an instance (not data but declare a type) of Foo[Self], we also set the parameter Self to that instance that was declared. So that is HKT. How do you think about and visualize HKT? |
|
|
|
|
|
finitemaz
Member
Offline
Activity: 87
Merit: 10
|
|
May 20, 2016, 01:54:49 PM |
|
AnonyMint still here?
|
|
|
|
|
|
iamnotback
|
|
June 15, 2016, 03:23:13 PM
Last edit: June 15, 2016, 08:00:34 PM by iamnotback |
|
Steemit sets a precedent for a similar method for insuring distribution is fair, as was planned for JAMBOX even before I read this: Rate Limited Voting
A major part of minimizing abuse is the rate-limiting of voting. Individual users can only
read and evaluate so many work items per day. Any attempt to vote more frequently than
this is a sign of automation and potential abuse. Through rate limiting, stakeholders who
vote more frequently have each vote count for less than stakeholders who vote less
frequently. Attempts to divide tokens among multiple accounts also divides influence and
therefore does not result in a net increase in influence nor bypass the rate-limit imposed on
voting.
But note JAMBOX will not use voting nor any centralized means of initial (i.e. issuance) distribution. The rate limiting will be applied differently. Note I disagree with the economic design of Steemit. Instead if users want to vote to send money to content creators, then let them pay minute microtransactions for each up vote. Steemit's collectivism instead encourages stealing allocating from the collective to pay for it. The payment for voting can be entirely opt-in, as it can be tied to priorities that users assign to content they are viewing. More details later... The concept of a globally tracked/enforced reputation metric is to me an anathema and the antithesis of decentralization. This is another difference in the design of JAMBOX and Synereo as well. I think I summarized best recently the difference in my thought process about decentralization when I compared The DAO to DVCS open source: - ... Decentralized version control open source (DVCS) solves this discord to obtain resonance by allowing every participant to have their own perspective on changesets. DAO is entirely wrong model for decentralized production. It fights against everything we learned with decentralized open source development, which is that the individual should be empowered to act independently.
Whereas, Steemit lumps everyone into the same boat and tracks it all on a block chain and forces everyone into the same protocol. I have much generalized vision, where every individual can run their own choice of protocol, GUI, rules, etc.. Synereo is somewhat closer to my vision, but they also tack on systemic relevance to the reputation system. |
|
|
|
|
|
Poll
