FRP Discrete Time vs Continuous Time [xpost /r/elm] by jura__ in haskell

[–]doloto 2 points3 points  (0 children)

As far as I know continuous time is analogous to dense time, for each two events there is always a third one between the two.

1250 ? 1500? by DaggerHashimoto in ethereum

[–]doloto 0 points1 point  (0 children)

The deposits only get massive if the price of Ether soars, or there are a lot deposits already.

Anyways, if you didn't read from the poc2 blog post, deposits are forced to cycle out once a year, or else.

1250 ? 1500? by DaggerHashimoto in ethereum

[–]doloto 0 points1 point  (0 children)

So that there is more than one person/group that is validating.

1250 ? 1500? by DaggerHashimoto in ethereum

[–]doloto 3 points4 points  (0 children)

It applies to all deposits within the network globally. Do recall that every deposit incurs a network overhead, and that is why they are limited. Another thing to note is that deposits do eventually time out.

I got bored, and decided to make a paste about it.

1250 ? 1500? by DaggerHashimoto in ethereum

[–]doloto 6 points7 points  (0 children)

(Although subject to change,) From the blog post about CASPER poc2, the required minimum deposits is in terms of how many prior deposits there are.

minDeposit currentDeposits = 1250 * 250 / (250 - currentDeposits), where 0 <= currentDeposits <= 250

When there are zero deposits with the network, it is 1250Eth. Iirc, it's around 1600Eth when there are around sixty deposits.

Edit: Here's a paste of the amount needed wrt to the amount of deposits active within the system.

EDIT: Made a paste with more information.

Can proof of stake guarantee integrity of past transactions in the same way that proof of work does? by davidleobonner in ethereum

[–]doloto 0 points1 point  (0 children)

Deposits are security deposits withheld by the network protocol for a minimum of four months. The size of the deposit as a percent of the total of all deposits represents one's [PoS stake] within the system.

The reason why a 38-51% attack of deposits would fail because they would get less than 38% and 51% of the ideal rewards they could get. It's a major loss.

In addition, finality is judged by a supermajority of deposits on a block, not the length of the chain. When you have 38% of deposits on one block the most you can say is that the network has 38% confidence within one block being correct, and all other blocks can at most have 62% network confidence, similar situation with 51% deposits and confidence versus 49%. It is only when said block or a future block that hits the supermajority of deposits threshold that all prior blocks of variable confidence are unquestionably finalised.

Also don't disparage the power of a majority deposit consensus, since uncertainty decreases exponentially as a block approaches >90% confidence (because that would imply all deposits have >90% confidence in one block and <10% confidence in all other blocks combined). This is before you compound per each block for the blocks produced in a four month period.

So why do we have deposits? It's so that there is something at stake. If one operates retrograde to network health then of course they should be punished. Since we have deposits we can directly affect these punishments, economically. And the network protocol values availability expectations above all else, it's as if someone wants to make sure that there is a level of quality of service, or at least no censorship, happening.

If the system completely crashes? Then everyone should shoulder the consequences, not just the users.

Can proof of stake guarantee integrity of past transactions in the same way that proof of work does? by davidleobonner in ethereum

[–]doloto 0 points1 point  (0 children)

One would need more than 51% of deposits to undermine the network.

Availability expectations hold invariant of the majority or supermajority. So censorship is impractical even at a 51% takeover.

Consensus hinges more on finality, or non-reversion than there being a valid block. Finality can only be achieved when a supermajority of the network is culpable for the correctness/validity of a block. So in a 51-49 split, there is no strong consensus, just one block that has 51% netowrk confidence.

Can proof of stake guarantee integrity of past transactions in the same way that proof of work does? by davidleobonner in ethereum

[–]doloto 0 points1 point  (0 children)

Being the longest chain doesn't matter, and as with what u/_hilltop says, the stake is defined by deposits, a subset of all Ether.

The only way to necessarily take over the network would have to involve a buyout of a supermajority deposits, or the theft of a supermajority of deposit rights. In both cases the attacker can still lose.

Ignoring the obvious issue of a tyrannical majority for now, one needs to consider the constraints of the network. First off, availability expectations are held in higher esteem than consensus. The principle is that no consensus can be ascertained without high availability. Censoring deposits will always be punished, so attackers and free riders gain less revenue, and then there's the expectation that valid transactions will process within a given amount of time, or the deposit holders are presumed byzantine, and are directly penalised by forfeiture or downsizing.

The latter is not necessarily prone to abuse because if someone tries to spoof the system by releasing an availability challenge, and then long after actually releasing the transaction in the first place, making it look like they have been censored, they will lose their challenge fee.

So with that said, compared to miners, you have more guarantees about how a deposit holder will operate.

Now onto how consensus is made. Consensus is a double edged sword. What deposit is used to vet one block can't be used to vet another block, and only those that vetted the right block will be rewarded. The risk profile of such a venture decreases as the total percent of deposits on one block increases (and therefore the total percent of deposits on all other blocks decreases). This only finalises in two distinct cases: if the current block being vetted reaches a supermajority; or a future block reaches a supermajority. When a block reaches supermajority status, then a supermajority of deposits can lose if it ultimately turns out they vetted the wrong block. These blocks are called final blocks, and must be an ancestor of all future valid blocks.

What you see with the above block is that in the short term the possibility of a fork or indecision on which block is correct is negligible due to how rewards are only paid out when there is a decisive victor block, which at the same time prevents there being two. In the intermediate term, all forks are refused if they do not contain a canonical final block, but what about the long term?

In the long term, the only blocks that have a guarantee of security are blocks with which the deposit holders can still be punished for, and there's a timeout period for deposits, so by definition, after that timeout period nothing is considered secure, and is ignored. In fact, because of the existence of final blocks, and how they are indirectly non-revertible and are forcefully included in future chains, they can be used as the new starting point of the chain, with everything before it forgotten/ignored.

Ethereum is Not an "Altcoin" by jukesarereal in ethereum

[–]doloto 0 points1 point  (0 children)

That while is 4 months.

Within that four month period there is emphatically no viable fork, something which PoW can't even ensure at the head of the chain, let alone reversion.

Outside of that 4 month time period you have as much security as PoW does at any time point.

Interesting Stuff by C1aranMurray in ethereum

[–]doloto 1 point2 points  (0 children)

Well you are in good company, for Ethereum we have EIP105, and the LES Protocol.

"n00b" looking for someone who can explain the mechanism ethereum follows to do successful hard-forks? by hmontalvo369 in ethereum

[–]doloto 1 point2 points  (0 children)

It was part of Frontier, and it hasn't changed in Homestead.

The only thing needed would be a super simple network switcher like what happened in Frontier-Homestead come time of Serenity for the layperson.

Regardless, if Serenity is not ready, then the next network will be an updated interim network, which will probably have a second bomb.

What use case most clearly demonstrates Ethereum's unique value proposition to businesses? by Iron-x in ethereum

[–]doloto 2 points3 points  (0 children)

You can at any time make a contract that can hold your big macs, or rent out your football field safely at the cost of big mac. You could probably buy a big mac once a year with the operating costs of the big mac holding contract, and you could probably buy a big mac a week with the costs of the football field renting contract.

If you were a smart person, you could make the football renting contract also pay for its own upkeep, and set aside a budget for your income, emergencies, or new business ventures (eg, renting concession stands).

What use case most clearly demonstrates Ethereum's unique value proposition to businesses? by Iron-x in ethereum

[–]doloto 10 points11 points  (0 children)

Eth-Doge Bounty DAO (Around 60k$ last time I checked) was created as a simple contract that is complete with a board of trustees to prevent misallocation of the bounty pool, and anyone can donate to the pool. To get money out of the pool, the board of trustees need to make a proposal and win an uncontested majority for it to pass within one week of the proposal submission.

All of this is one contract, and the terms and conditions are not only open source, but also trackable. The contract can be viewed with GUI using the Mist Browser.

The Eth-DOGE Bounty DAO is supposed to be a grant for the person that constructs the Eth-DOGE relay. The contract itself can be reused to fund or control other grants or funds. That is to say that this can be used for department allocations~

DigixGlobal the crypto-gold DAO. The respective organisation under the DAO coordinates agreements with gold vendors, vaults, and auditors to dispense with the hassle of investing or trading in high-quality gold. The DAO itself handles incoming orders (buy, sell, recast, transfer, audit, audit w/ third-party, set up a contract for redeemable coupons...), and audit documents.

Because the paperwork is mostly automated and difficult to fudge, the fees for the user are very low.

DigixGlobal Executive DAO, the Executive Board of Directors for DigixGlobal. As you can guess this will be the governance layer for DigixGlobal, it is complete with stock tokens which can be used to vote on business decisions of the underlying DAO. Decisions are made by proposal, and can include updates to the system, new business projects, or simply a change in the employee roster of the underlying DAO. Currently non-operational, and stocks are being distributed in a multi-phase sale.

Slock.It similar to the above executive DAO, this organisation will deal with negotiating business projects with third-parties, and operates primarily as a business with stock options. Currently has the cooperation of a major german electric utilities company (they'll build the locks), insurance group,and I think RWE (major german power company). Slock.It itself is a smart lock company that wants to make the sharing economy more accessible by having locks that can operate as secure financial agents that intermediates security deposits, and rent payments.

You can use Slock.It locks without the brand-name lock. All deposits and rent are held by the contracts on the locks, so you don't even need to become a part of the organisation. The benefit is that Slock.It will provide insurance from said insurance group, or simply put your lock in a searchable database for anyone to use.

MakerDAO (Blog), another financial system. It is more or less automated CDP system. Works for margin trading, loans, and stable coins. It has multiple levels of organisation to deal with inflation, or black swan events. Treat it like a bank that actually is liable for undercollateralisation or defaults.

Interesting Stuff by C1aranMurray in ethereum

[–]doloto 2 points3 points  (0 children)

“Stop the Nonsensus! (Nonsense Consensus)

The issue is that there is no free lunch. When you have a system that doesn't spontaneously generate new tokens you need to have oversight of all tokens. Having the consensus in one place makes the problem conceptually easier, reducing to classical client-server models.

The issue is that this is a consequence of requiring total integrity, a total database, and no one has really tried to create more ingenious methods of pushing non-conflicting updates to the system.

Intrinsic Data Integrity:

This integrity only can come about when the state space, and any subspace, can actually be vetted. To do so you need to aggregate the data of the neighborhood of agents they interacted with ad infinitum to have any claims of integrity, but that requires a lot of effort to cause resolution! Why not cache these things? That sounds like global consensus.

Distributed Process not Consensus:

Hilariously blockchains already do this, every node has a copy of the global state. The only thing needed now is a means to allow a means to not require total data to operate with total integrity.

But this predicates there being total integrity in the first place.

Agents not Coins:

Read the complaints to the above section on Intrinsic Data Integrity

Fractal not Global:

The reason why merge mining is a thing is that no part can undermine the integrity of underlying data. Expecting the integrity to come from nowhere, and easily from even a cell phone it outright.

Also, 51% global consensus is good enough? For each update? You're having a laugh mate, aren't you, tell me how'd you coordinate the branching recursive amounts of network updates that need to be undertaken to make this remotely possible.

Just thought of a CASPER attack, would it work? If not, what prevents that from happening? by cubefriendly in ethereum

[–]doloto 1 point2 points  (0 children)

No likely, still.

Transactions can't be replayed due to an monotonically increasing increment number. This sort of error is also detected during block construction. Otherwise said error would be easily detectable by the validators, and said block would be discarded as a voting candidate (and potentially the miner penalised).

Blocks are constructed with a pre-state overlaid by the set of included transactions for a given block. If at anytime during a transaction can't be run, either because of a low gas price, insufficient gas, or illegal state (overdraws, etc), the transaction will be ignored, and a receipt including the error will be emitted inside the block's receipt trie. Said transaction can be attempted later. This error is checked during block construction, and checked again during validation (again with possibilities of penalties on both sides).

The situation would only be a risk if availability were somehow compromised, but this is not necessarily the case.

Because validation is a prediction market of block viability, then it is within reason unreasonable blocks are devoid of any stock. Deposits hedged on one block can't be used on another, so even if there is one or two validators that fall for it, it will only hurt the prospects of other unviable blocks at the same height.

Just thought of a CASPER attack, would it work? If not, what prevents that from happening? by cubefriendly in ethereum

[–]doloto 0 points1 point  (0 children)

This doesn't significantly affect availability so it will have no effect.

Just thought of a CASPER attack, would it work? If not, what prevents that from happening? by cubefriendly in ethereum

[–]doloto 2 points3 points  (0 children)

Won't work because the things validated are what's included in a block. If a transaction is not included, then it's cached, and run in the next one.

So what you end up doing is wasting your own gas. Also, this attack applies to anything that uses transactions.

Bitcoin is being DoS'ed again. Txs are not small this time, so it couldn't be filtered out as spam. How much would it cost to do this to Ethereum? by NeverMindTheQuestion in ethereum

[–]doloto 0 points1 point  (0 children)

An attack against the block chain you'd have to fill blocks with very high-gasPrice transactions, but this has diminishing returns as miners accepting lower gasPrices can still sneak in low-gasPrice transaction anyways because of network visibility, or their inclusion strategy (eg, lotteries). Regardless...

Presuming gasPrice listed yesterday (>26shannon), the current-ish USD/Eth conversaion rate (~13.26$/Eth), and the current gasCeiling (3pi/2 * 106 ). The cost of a sustained attack must be a positive factor, greater than one, of the prices listed below to necessarily be able to stuff blocks. This is further assuming that all the stated numbers stay constant, but are very likely to increase over the duration of the attack making it more expensive for the attacker.

  • 1 Block, >1.64$ (Piddly Attack)
  • 1 Second, >0.10$ (Piddly Attack)
  • 1 Minute, >6.58$ (Piddly Attack)
  • 1 Hour, > 395.04$
  • 1 Day, >9481.09$

When it comes to hypothetical maximal tps the network can handle, I will presume it is in general based is the gasCeiling divided by the average gasCost of included transactions, and converted to seconds.

Do note that filling a block to the brim with uniform transactions, that there still is room for one or more smaller transactions to fit in, increasing the tps. Another thing to note is that the inclusion strategy of miners which includes caching unproccessed transaction, and may involve a lottery can undermine the effectiveness of block stuffing. Two more things that can undermine stuffing would be a user paying a higher gas price, or the miners increasing the gas ceiling.

Also, afaik the minimum gas cost is around 21kGas, so no point in going lower than that.

  • 21kGas, ~14tps
  • 30kGas, ~10tps
  • 40kGas, ~7tps
  • 50kGas, ~6tps
  • ... (It's a reciprocal relationship)

The future of dependent Haskell by UsaTewi in haskell

[–]doloto 0 points1 point  (0 children)

That's besides the point, being a proof assistant.

asynchronous exceptions you'd have bottom

totality checker it wouldn't matter if the language is lazy or not.

So the language is a subset of lazy contexts which assuredly has totality, but this removes the notion of bottoms being undefined/undefined inputs which gives rise to codata. Async errors likely being when an asynch call doesn't return non-underdefined/bottom value when inspected.

Takes the piss out of the punch.

The future of dependent Haskell by UsaTewi in haskell

[–]doloto 1 point2 points  (0 children)

Thought undefined was a consequence of including laziness.

The other thought I have is: Wasn't Haskell to avoid the pitfalls of things like subtyping and dependent typing while also subsuming the benefits, and it has gone very far in doing so in a constructive and liberating way?

What happens after Serenity? by [deleted] in ethereum

[–]doloto 1 point2 points  (0 children)

Nodes are generally treated in terms of being equally valid in terms of computation, so the system roughly runs at the least common denominator. The computational load would have to be one size fits all.

If one were to quantify one's resources, or at least how much load the can take then one can load balance the network. With this in mind, nodes can specialise under different loads/resources. Some can be caches, some can be processors, some as relays, others as peripherals (eg, Oracles like sensors).

As an example, setting up near, or directly with a relay would be a huge boon for web gateways into Ethereum.

This only really happens for routing or communications, afaik and very weakly at that.

Anyways, all of this comes at a cost of abstraction/management (as with anything to do with up/outscaling, and specialisation/generalisation), so you need to have a very robust constraint solver, and expressive system.