pipermerriam

From my point of view, the US Government has not acted in such a way that they deserve to be extended any "benefit of doubt". The three recent events linked below come to mind as supporting material.

They have consistently demonstrated their willingness to break the law when it is inconvenient for them, as well as actively working to expand their power and authority at any expense.

1. Raid of Tor Exit node - http://www.npr.org/sections/alltechconsidered/2016/04/04/472...

2. Hair Follicle Analysis - http://www.theguardian.com/us-news/2015/apr/21/fbi-jail-hair...

3. Manufacturing Evidence - https://theintercept.com/2016/05/05/fbi-told-cops-to-recreat...

> If there were automated ways to create a corporation and give it legal personhood, along with an offshore bank account, the possibility of the emergence of self-sustaining autonomous corporations may become more of a certainty.

Take a look at the [DAO](https://en.wikipedia.org/wiki/Decentralized_autonomous_organ...) concept. These are currently being built and deployed on the Ethereum platform. Sounds like a real world version of what you are theorizing.

Developing on the platform right now is akin to writing software to run on a VM that has no operating system. The services that are being written right now can be thought of as the operating system (foundation) that everything that will come next is built on. To do the really interesting stuff you have to first build all of the really low level tooling to support it.

There's a lot of talk about replacing Uber/AirBnB/Facebook/etc with decentralized applications but I believe those things are still at least a few years away. Complex applications like those are going to require significant base infrastructure that just doesn't exist yet.

The "Trusted" inputs problem is complex and I don't believe there will be a single solution. Some applications will be fine using trusted oracles. Others will need a more trustless model which is going to require on-chain reputation systems which in-turn is going to require some level of identity/anti-sybil system.

> Give me any ethereum use-case & I'll tell you how to do it with bitcoin.

I'm failing to see your point. Does the fact that things are possible with bitcoin make the technical merits of Ethereum less in some way?

> What I do not like in ethereum is the nature of origin of ether which makes it just an IPO coin.

The "makes it just an IPO coin" statement also seems to discount any of the technical merits of the platform due to your dislike of how the initial coin distribution occurred.

Disclaimer: I stand to benefit financially if the platform succeeds.

Have you read up on the proposals and information on plans for Proof-of-Stake (Casper) and Scaling/Concurrency via sharding? Both of those are directed at fixing the "fast enough" problem.

This sounds awful similar to the "Nothing to hide argument". People have a right to privacy and shouldn't have to provide a reason why they deserve it. Tracking should always be opt-in.

https://en.wikipedia.org/wiki/Nothing_to_hide_argument

Quite fair and message heard and received. I hope you can take this for what it is, an oversight rather than intent to deceive.

I still stand behind everything I said regardless of the technology that ends up accomplishing it. I chose to mention Ethereum because I think it has the best shot. If Ethereum fails, I'll be looking for the next best viable option for a decentralized internet.

I thought about adding the disclaimer and chose against it. Maybe I chose wrong. I sort of see your point about conflict of interest, but that line of thinking also disqualifies almost all of the people who are most intimately familiar with the technology.

If you're skeptical, lets have a conversation about it. I regularly describe my position as skeptically optimistic about Ethereum's future success.

I've come to believe that "the powers that be" will never stop this progressive march towards pervasive monitoring and surveillance. If we succeed in keeping this bill from passing, we'll just be fighting another just like it or worse in a few years. We have to make it fundamentally impossible to monitor our private communications and to share our private data.

To get there, it is going to take a complete shift in how we build internet software. These problems cannot be fixed using the current status quo. I highly encourage you to start looking into projects like Ethereum, IPFS, Whisper and Swarm. The offer a way to build web applications that are completely immune to censorship, monitoring, and large scale data breaches while giving user's control over their data.

This isn't to say that there aren't battles to be fought in the legislation arena. There are and kudos to entities like the EFF for leading the charge. What I'm trying to say is that as long as it's possible to do pervasive surveillance, we're going to keep seeing the powers that be continue in that direction. If it is possible, they will try and do it.

Sources:

* https://www.ethereum.org/

* https://github.com/ethereum/go-ethereum/wiki/Swarm---distrib...

* https://ipfs.io/

* https://github.com/ethereum/wiki/wiki/Whisper-Overview

Despite how troubling this is, I have trouble accepting that end-to-end encryption is useless. It still offers significant protection from being monitored even if that protection can be theoretically circumvented by lower level methods.

Looking through the getting started, one of the instructions is to run geth with the following flags. `--rpc --unlock 0 --rpccorsdomain "*"`.

Please be very careful with these two flags as they will allow any malicious javascript on any page you browse to empty your ethereum wallet.

https://github.com/ethereum/mist/releases/tag/0.3.6

Also, this looks really cool.

Cannot recommend this enough. Strong female lead character. Entertaining enough for adults to watch. Math!

Yes to this.

Thus far it is shaping up to be a powerful platform with some realistic potential to changes to how internet software is built.

Can you please back this up with some actual citation or something. I'm pretty involved in the Ethereum community as a developer and this statement seems founded either in fantasy or in information that I'm not aware of.

> Ethereum's chain is a mess.

I'm unsure what you mean here.

> It's only burning 25k USD per day, and the project plans to switch off of it entirely.

Burning 25k USD of what? Switch off of what?

> The claim that this project can cure whatever ails you on such a weak foundation is at best dubious, and probably just a scam.

Which claims are you referring to. What part of Ethereum is a scam?

This is an honest question.

Realistically, how do we dismantle the police state. It seems like the NSA, FBI, and some not insignificant percentage of the police forces have gone entirely rogue or lost track of their mission entirely.

It feels hopeless. So much outrage but so little actual ever changes. Does anyone have any ideas because I'd love to hear them.

I haven't heard it put that way, but now having heard it, I like it a lot. Thanks for giving me a new way to talk about this sort of thing.

@vessenes, I would ask that you backup that assertion with an actual explanation of why Alarm should never be used for Augur.

Just saying it shouldn't be used isn't very constructive.

Edit:

If I make some assumptions about why you think it's a bad idea then I would guess it is that you think the call executors can behave badly in some way. The way the call execution works is that as long as there is at least one honest caller, then calls cannot be censored. Call execution is a binary operation as the executor can't control the call data. So the only thing a call executor has control over is whether or not they execute the call. Even in the situation where some attacker represents a large part of the caller pool, there is a section during the last part of the call window where anyone may execute the function call in exchange for a large payout. So even if an attacker is operating 99/100 of the accounts executing function calls, that 1 honest person can execute the call if everyone else chooses not to.

A point of clarification. All call execution is just a ping. If the call requires call data it is supplied by the scheduler and cannot be manipulated or changed by the caller. All call execution is relayed through the alarm service so it only relies on the executor to initiate the transaction and then the alarm service does all of the rest.

* Recurring and Scheduled payments. On the first of every month, the alarm service pings my wallet to pay my utility bill.

Most of the other potential applications it's easy to argue that they could set up their own incentives to get some user in the system to execute the call. (lottery payout, scheduled trade, crowdfunding payout, etc).

I think that yes, each of those applications has a viable way of motivating some party to execute the call. However, if a service like Alarm proved to be very reliable, it may be simpler to just automate it with a scheduling service. Scheduled or recurring execution doesn't have to be the only solution to a problem for it to still be a good solution.

I think the number of transactions/second will always be reached before demand could outpace the ability for people to execute the calls.

You are correct that it would be an interesting world if somehow demand for scheduled call execution spiked to some massive number that outpaced the ability to execute them. I am having trouble thinking of realistic scenarios where that happens but that doesn't preclude it as a possibility.

Executing a scheduled call is always profitable, so no. People would just make less money.

The market aspect is more akin to a marketplace where people are hired to do a job. And the job is entirely automatable.

Calling contracts has to be profitable, otherwise nobody would do it.

Since there is no way to reject a transaction, every person who attempts to execute a scheduled call will have to pay some small amount for the transaction. If the service is implemented as a first call wins sort of thing, then all of the people who tried and failed would be out the gas cost of that transaction. For calling contracts to be profitable, these costs would have to be covered somehow, otherwise there is no incentive for people to execute calls.

So, this cost would have to be offloaded onto the people scheduling calls which would cause a significant increase in the overhead of scheduling a function call.

The alternative solution I came up with was having a caller pool. The people executing the calls are guaranteed a window of time where they can call the contract and also incentivized (by their bond) to fulfill that duty lest the next person in the pool claim their bond.

I'm open to alternate solutions to this problem.

A contract is the term for an application that has been deployed on Ethereum.

Contracts expose functions as an API that others can use to interact with them.

On Ethereum there is no built in way to have a contract be called periodically, say every 5 blocks, or at a specific time in the future. This contract creates a market which allows contracts to hire people to call them at the requested time.

I'm curious if you would expand on why this is a terrible idea.

I'm the author of the service.

This is a fundamental limitation of the network as opposed to a shortcoming of the service. When you submit a transaction, it is up to the miners as to whether it gets included in the next block. There are lots of factors that go into this decision, and in normal situations, transactions are going to get included in a block very quickly.

If you accept the assumption that there are enough people executing calls (in exchange for $$) and that the network is not so flooded with transactions that miners are having to exclude them due to volume, then the likelihood that your function won't be called drops near zero.

If the network is congested with too many transactions, then it doesn't matter if the call was triggered by the alarm service or somewhere else, it will still have to compete to be included in a block just like any other transaction.

Now if you want to talk about selective censorship of function calls, then that is an interesting attack vector that I'd love to chat about.

fun.

https://gist.github.com/pipermerriam/d1b5a24230f2f9ec4446

In all seriousness, what can I actually do. Nothing I've done in the past has felt like it moved the needle at all.

- Calling my local representative (Someone on the other end of the line thanks me and then politely dismisses me saying they'll pass it along). - Trying to inform friends and family (They don't really care for many of the reasons stated above)

I think apathetic is a good descriptor for my current state of mind around things like this. Any effort I've put into large scale change in the past has felt like spinning my wheels and generally decreased my overall happiness due to general frustration. Letting go of caring about politics was a major happiness/satisfaction increase in my generall well-being.

I wrote a small application a while back to allow a team to figure out what their average salary was without exposing individual salaries. Seems relevant.

https://are-we-being-underpaid.herokuapp.com/

It generates unique URLS for each participant and stores almost nothing on the server. Only a party that was actively monitoring web traffic has enough information to divine someone's salary. No tracking of emails, salaries, etc.

Source code here https://github.com/pipermerriam/am-i-underpaid

I thought about that and had the following two concerns.

1. Prevent a malicious user from setting up a survey with only one other person's email address. 2. Ensure that everyone knows the full group that is being surveyed by including the list in the email (so that they can not worry about #1)

I can definitely see the value in being able to post a link somewhere and have people be able to just follow it to report.

Got any suggestions on how to deal with or mitigate the exploitation of the system in that manner?

I also can now see the downside in having everyone's email on the list. It makes it feel less anonymous. Seems like you have to trade one for the other. True anonymity and ensuring salary data doesn't leak.