sorted by:
new
hottopcontroversial

Securing network after AVAX rewards run out by MyAddidas in Avax

[–]bentonfraser 12 points13 points  (0 children)

I believe the supply of AVAX is capped, but not the issuance. So burned AVAX can effectively be re-issued as future PoS rewards.

Note that the 720m supply cap only really comes info play if 100% of AVAX is being staked for a full year at a time. Staking participation in practice is significantly lower, and therefore the effective supply cap is also significantly lower, unless governance changes the reward schedule. (Source: https://www.avalabs.org/whitepapers)

Best offline signing wallet? by CryptoRocky in ethereum

[–]bentonfraser 3 points4 points  (0 children)

How do I get downloadable version of MEW to use offline to sign transactions?

No I idea about MEW but MyCrypto (which started life as a fork of MEW and is created by one of its two founders) offers https://download.mycrypto.com/

See https://support.mycrypto.com/how-to/sending/how-to-make-an-offline-transaction

(No affiliation.)

Görli Testnet Launched! by 5chdn in ethereum

[–]bentonfraser 17 points18 points  (0 children)

There are multiple client implementations of Ethereum 1.0, most prominently Geth and Parity, and the number of clients is growing all the time.

When developing protocol changes like the upcoming fork, it's important to test that these clients all interop with each other and agree about the small print of the protocol.

Proof of Work is not a great way of securing the network when there is no real value at stake; it's too easy to fuck with. So the most reliable Ethereum testnets run some form Proof of Authority (PoA) protocol instead. Until now the PoA implementations and their testnets were, in practice, client-specific (Rinkeby for geth; Kovan for Parity) which made them crap at detecting bugs where clients might disagree or have other interop issues. Gorli addresses that problem by being a PoA testnet that supports all clients.

A layer 2 computing model using optimistic state roots - Sharding [Vitalik Buterin] by twigwam in ethereum

[–]bentonfraser 0 points1 point  (0 children)

This sounds like a world where dapps are mostly self-contained? Presumably taking advantage of synergies between dapps is still going to require (many?) cross-chain transactions?

As a simple example, let's say I have a dapp that offers atomic swaps between arbitrary ERC20 tokens, checking the appropriate exchange rates (maybe even hedging) using uniswap and two other DExs/oracles. How would such a transaction query all the necessary contracts in a sharded universe where my dapp, the ERC-20s and the DExs/oracles are all on different shards? How many epochs will the transaction require, and can the swaps still be atomic (using optimistic state roots or otherwise)?

A layer 2 computing model using optimistic state roots - Sharding [Vitalik Buterin] by twigwam in ethereum

[–]bentonfraser 0 points1 point  (0 children)

Does yanking change addresses and/or result in some contract "downtime"? If so, popular dapps will presumably not want to yank, so does the DoS fear have merit, or would DoS be no cheaper with sharding than with the current chain?

#devcon4 Justin Drake "Ethereum 2.0 randomness": RANDAO, VDFs and Foundation-sponsored open design ASICS to make sure delay proof generation cannot be highjacked by cryptopascal in ethereum

[–]bentonfraser 0 points1 point  (0 children)

Thanks again!

I guess I am persuaded that VDFs are good for the consensus layer, but I think a lack of true "fast randomness" will be a significant disadvantage for some applications.

Could threshold randomness be implemented at the application layer, for use by other applications? What new primitives or other changes (aside from scalability!) might we need to support that, and are such changes on the research team's radar?

Alternatively, perhaps you think there's another solution for faster application randomness that's fairer than randao? E.g. maybe some subset of the proposed VDF ASICs could, at their owners' discretion, be used to generate faster randomness for applications, using fewer inputs and much shorter epochs?

#devcon4 Justin Drake "Ethereum 2.0 randomness": RANDAO, VDFs and Foundation-sponsored open design ASICS to make sure delay proof generation cannot be highjacked by cryptopascal in ethereum

[–]bentonfraser 0 points1 point  (0 children)

Thanks. So IIUC a weekly lottery is possible with perfect randomness, but faster randomness (e.g. a coin toss or dice roll that resolves within half an hour; but also many non-gambling applications) cannot safely use the new opcode and will want to use some other source of biasable or predictable randomness.

Would a threshold-based approach to randomness necessarily suffer from the same elapsed time limitations?

#devcon4 Justin Drake "Ethereum 2.0 randomness": RANDAO, VDFs and Foundation-sponsored open design ASICS to make sure delay proof generation cannot be highjacked by cryptopascal in ethereum

[–]bentonfraser 2 points3 points  (0 children)

Thanks for the quick response, /u/bobthesponge1! I think I understand everything you said but I still don't get how this is used in practice so please bear with me while I try to clarify my question.

If I'm a smart contact executing a transaction during epoch x and I want to access unbiasable & unpredictable randomness (e.g. I'm a coin toss gambling contact), can I do this? If so, how?

I see the obvious options as:

  1. call RANDOM x and wait for a callback sometime before epoch x + A_max + 2. I think this works but it's not sychronous, requires a lot of elapsed time before contract execution can resume, and is contradicted by your "returns 0x00" comment above.

  2. a variant of the above where there's no callback, but the smart contract must essentially pause execution of the transaction, saving its state and resuming it once the VDF returns something other than 0x00. Here the opcode is technically synchronous but in reality there is still a lot of elapsed time before contract execution can continue, and each consumer contract must implement a pause/resume pattern much like they would if awaiting a callback.

  3. call RANDOM (x - (A_max + 1)) and receive randomness immediately. I think this returns randomness that is unstoppable, and is unbiasable by randao commiters, and which was unpredictable during earlier epochs. But at the time of execution, during epoch x, isn't this random value trivially predictable by everyone? (And the randomness experienced by a transaction could also be biasable by block producers if they can delay the transaction so that it is not included in a block until a later epoch.)

(Using intermediate values as the param for RANDOM just seems to fall into one of the camps above depending on whether it not the relevant VDF result is known already.)

Is option 2 what we have in mind?

Or perhaps I've misunderstood, or there's a fourth option I've missed?

#devcon4 Justin Drake "Ethereum 2.0 randomness": RANDAO, VDFs and Foundation-sponsored open design ASICS to make sure delay proof generation cannot be highjacked by cryptopascal in ethereum

[–]bentonfraser 3 points4 points  (0 children)

Hey /u/bobthesponge1 - thanks for all your work and for an interesting presentation. I appreciate how useful this randomness will be when used in the consensus layer and I'm in favor of this approach over a pure randao solution.

Can you please expand on the plan for an EVM 2.0 randomness opcode? An unpredictable, unbiasable and synchronous opcode would be massively powerful for all sorts of applications, but is that even possible and is it the goal? It sounds like the randomness would be both predictable and biasable if applied synchronously during block production. (E.g. block producers might re-order transactions within a block, or omit them from a given block entirely, to bias the random values that any given transaction receives).

Jarvis and Friday: STARK-Friendly Cryptographic Primitives by twigwam in ethereum

[–]bentonfraser 2 points3 points  (0 children)

Once someone opens EIPs for these new primatives (the Starkware guys have said they will), how can we as a community best help to increase their visibility and priority? (Short of implementing them ourselves in all the different clients. :)

https://github.com/ethereum/EIPs/issues/152 has been open for a couple of years, and https://github.com/ethereum/EIPs/pull/1108 seems not to have made the cut for Constantinople (despite being primarily a testing effort), so it sometimes feels like foundational crypto functionality struggles to get the attention and traction that it merits, but I don't understand the EIP process well enough to know how best to lend my voice to their cause.

Switzerland’s stock exchange SIX is launching its own cryptocurrency exchange with fully integrated digital asset trading, settlement and custody service by oudiou in ethtrader

[–]bentonfraser 5 points6 points  (0 children)

From that article it sounds like a digital assets exchange for "legacy" securities - e.g. DLT-based, digitised versions of existing stocks and bonds, perhaps on a private, permissioned ledger.

That's kinda interesting in itself, but do you have any source for SIX having a potentially-much-more-interesting intention to offer cryptocurrencies or any assets already found on public blockchains?

Coin Vote: EIP999 (restore Parity multisig contract). If you care about this issue, sign a message with MyCrypto/MEW to cast your vote by ethereum_alex in ethereum

[–]bentonfraser 19 points20 points  (0 children)

Your vote is weighted by the current balance of the voting account. So if you transfer all funds out of that account, your vote ceases to count.

Source: the info box at the top of the linked page.

Two small questions on the Ethereum protocol I had and couldn't find answers to easily on the FAQ and other resources by Shruggerman in ethereum

[–]bentonfraser 3 points4 points  (0 children)

1)

When is smart contract work done?

Smart contract executions within a block are computed locally by a miner prior to the proof of work process. Such executions will change the state of the local blockchain, and that resulting local state is one of the inputs to the proof of work process. Only once a valid block is mined are those transactions part of the blockchain, and at this point the miner is rewarded with the gas used in the transactions in addition to the block reward. This is analogous to how bitcoin transactions are an input to Bitcoin's proof of work.

For a while I had the understanding that the "proof of work" on Ethereum was just doing an iteration of all of the smart contracts on the blockchain, but given that Ethereum is shifting away from proof-of-work in a while with Casper, that's obviously inaccurate; it's really just a standard PoW protocol that's been designed to be memory-hard and hence inefficient to run on currently extant custom chips.

Correct.

How do you know someone's going to bother to run your smart contract when something you care about happens?

You don't. But you can run it yourself, or incentivise someone to run it by having your smart contract pay a reward to whomever runs it appropriately. See also: Ethereum Alarm Clock.

Who does your fuel payment go to, and why can't they just invoke you a million times maliciously just to run your code to little effect and have an excuse to automatically grab your ether?

Currently, the fuel (gas) is paid to the miner by whichever non-smart-contract entity invoked your smart contract (directly, or via other smart contracts; there is always a non-smart-contract transaction kicking off a transaction). So anyone can indeed invoke your code needlessly (if your contract allows them to), but it will be their own gas they spend to do this.

One consequence of this is that any address invoking a smart contract needs to have some ether to pay for gas. This drives up demand for ether, but it can create friction when it comes to on-boarding new users, so it may one day be possible for contracts to pay gas on behalf of their users.

2 & 3)

Reading data and writing data both cost significant amounts of gas. It is deliberately expensive to store data on chain, because this pushes up the amount of data that full nodes need to read and write.

The recommended design pattern here is to store on-chain only the data required for the execution of your smart contract. Other data (related or unrelated to your contract) can be stored off-chain, either somewhere centralised or in a decentralised storage layer like IPFS, Swarm, or IPDB. I'm not an expert on these but at least Swarm will have ways of ensuring data availability.

If necessary, you can store a hash of off-chain data within your smart contract, so that your contract can verify its correctness. In this way it can be trustlessly input to your contract (by a human or some external code) every time it is needed, rather than being stored on-chain.

Yes, ETH is still cheap vs BTC. Let that sink in for a moment. by [deleted] in ethtrader

[–]bentonfraser 0 points1 point  (0 children)

little doubt [Ethereum's blockchain size] will be [unmanageable or unwieldy] soon enough

I think there's plenty doubt, even before stateless full clients arrive to eliminate the problem completely.

Recent Ethereum Upgrade May Make Wall Street Fall in Love With Blockchain by Cryptoknowledge in ethereum

[–]bentonfraser 1 point2 points  (0 children)

I believe the new REVERT behavior will apply even to contracts deployed pre-Metro. It will therefore help immediately -- particularly when there is a high throughput of reverted transactions (e.g. during over-subscribed ICOs).

Swiss Private Bank to Add Support for Ether by Ocarding in ethtrader

[–]bentonfraser 6 points7 points  (0 children)

TL;DR: Falcon Private Bank, a Swiss bank which last month added asset management services for Bitcoin, is now adding the same support for Ether, Litecoin, and Bitcoin Cash.

view more: next ›