Didn't the "tokens backed by something off-chain, and then a fork happens" already happen with Digix?

I believe they just basically said "we are treating the tokens on Ethereum, not on Ethereum Classic, as being the ones which are redeemable". I don't see what the problem with this is. It is inconvenient for the people who prefer to use Ethereum Classic, yes, but they didn't lose their tokens. They still have control of those tokens on the Ethereum (ETH(F)) chain, and can sell those if they want to end up only using Ethereum Classic.

This is unfortunate for them, and if this inconvenience could be avoided for free, then that would be better, but I don't think it is unfair to them. They still have the same control over the same tokens that are accepted as legitimate as they did before.

Indeed, I don't think it's a deal breaker as well. There is a huge potential for scams, here, though (people buying invalid tokens for near than nothing on ethereum classic, then luring unawared people to buy them at full price misrepresenting them as the real thing). In this case, forks basically create counterfeits.

I don't understand how the stellar case and the bitcoin case differ in a network partition. You said "if Stellar fell apart and became partitioned, you would stay on DB's side."

How is that different from a network fork happening, and DB saying "We only accept tokens from ETH and not ETH classic".

At the end of the day, DB is deciding on a network partition to support, and you either support the network partition DB is supporting, or you don't do business with the DB tokens.

Note that in general there is no way to name a particular branch of a blockchain fork. In cases with a protocol change coordinated well in advance, a counterparty anticipating the fork could announce that their tokens on one branch will be useless. However, if you just have two competing mining pools duking it out with the same protocol, there will be no way to name the branches ahead of time.

What's worse is that colored coins could distort the incentive structure to make it profitable to bribe miners, because the benefit to an attacker of subverting consensus could far outweigh the value of 12.5 BTC/block.

I'm not familiar with the "trustlines determine partition choice" feature of Stellar, but I am with trustlines in general; they are explicit app-level concepts that you define on your wallet, which in this case would say something like "I trust DB to redeem up to 1m worth of EUR credits".

If the Stellar client's behaviour in the face of a partition takes trustlines into account, that's much safer than the default behaviour in bitcoin, which I believe is "pick a partition at (pseudo)random".

It's possible to manually coax the client to pick a partition, but that requires user interaction, i.e. it's not fail-safe, it's fail-unsafe.

Your justification for the Th/s being an issue for electricity consumption is one I have seen bounced around a bunch but other than the justification of the environment there are other issues. But, the idea of cryptocurrencies is that without some kind of artificial scarcity you will have other incentives. If you are really concerned about electricity consumption what about using a ledger technology that is designed for low resource consumption such as Sawtooth? I'm not sure how Stellar helps you in this regard. Also, why are you seeking more funding in the first place?

> I'm not sure how Stellar helps you in this regard

Stellar does not use proof of work.

> Also, why are you seeking more funding in the first place?

AFAIK Keybase are a for-profit private company.

"Also, why are you seeking more funding in the first place?"

What is the purpose of this question? You want KeyBase, a private entity, to convince you, a stranger on the inter-webs about their plans for said funding? That's giving yourself FAR too much importance. Here's $5 bet that the company will ignore this question.

Electricity consumption is not an "artificial scarcity"

I mean that artificial scarcity is enforced by a distributed ledger system is by using the concept of a miner. The best implementation we have so far that is electricity consumption because this makes people consume electricity which costs them money. If you don't have this piece then people will subvert the proof of work some other way.

For example if you have some type of mathematical problem (the unknotting problem) to take the place of the proof of work then you have to worry that that problem is actually hard to perform. Hypothetically that problem could be quite easy and you can subvert the system by having some shortcut.

But inverting a hash is known to be hard. Through this hardness you get artificial scarcity by making people efficiently design systems to consume electricity.

i wouldn’t say that’s true at all. proof of work isn’t the only “artificial scarcity” that we can have... its paying money to compute some thing to get a vote... why not just put money for a vote? or better yet, prove that you have the means to pay a lot of money for a vote.

if you have to hold a lot of limited thing X (that’s difficult to get; eg $10m worth of ETH) on the very chain you’re securing, then that’s scarcity too.

another benefit here is that you can make a trusted network; that way you don’t have nodes coming and going, you have a group of trusted parties with their own network, and there’s less potential for a 51% attack

electricity and work isn’t the only thing that can be scarce

I think scarcity is a bit of a red herring. The key is that it has to be more lucrative to play fairly than to cheat (well, it also has to resist attacks that are simply trying to destroy the service). Proof of work by itself is not enough. It's the scaling of the difficulty to the potential gain -- the implication being that more people mining == more money to be gained by cheating.

The other thing that is compelling about Bitcoin's proof of work protocol is the ideal that every participant is equal. The whole point is to avoid the circumstance where more money means more control. Now, I think we can probably all agree that this didn't pan out -- whoever controls the big mining pools controls the system. I think that if anyone is going to go to the next level they probably have to step back and look at the problem with fresh eyes. Substituting X into "Proof of X" is unlikely to provide the solution, IMHO.

Have there been changes to Stellar to address the topology trust issue that `nullc brought up in the linked thread?

Regarding electricity consumption, what do you think of the argument that mining is so competitive that it can only be profitable by subsidized electricity, and that electricity is only subsidized when the local jurisdiction is creating more of it than it needs anyway? In other words, mining doesn't actually create new demand for electricity, it just soaks up the remainder already available.

"electricity is only subsidized when the local jurisdiction is creating more of it than it needs anyway?" is false - there are a few cases of negative spot prices, which nonindustrial customers can't get, but all the rest of the time electricity subsidies are for economic and social reasons.

Normally surplus electricity results in a curtailment of fossil sources.

There is no such thing as "excess electricity". If that power wasn't being wasted on useless cryptocurrencies, then we could have used it for useful purposes, such as processing aluminum.

> no such thing as "excess electricity"

there absolutely is a disbalance between energy produced and energy consumed. if we're lucky, there will be storage capacity nearby. we're mostly not lucky. ever heard of australia? or tesla? google some.

> wasted on useless cryptocurrencies

yeah, transferring value securely without trusting third parties is not useful at all. gotta run all those banks and employ all those bankers, because that costs no energy nor other resources.

are you a banker by any chance?

If anything, crypto currencies will create more work for bankers.

Water power generated electricity

The Energy Waste Fallacy: https://github.com/libbitcoin/libbitcoin/wiki/Energy-Waste-F...

That argument makes no sense to me. It essentially boils down to "people can choose whatever level of security they want, so given that they chose the current level of security that must be the most energy efficient -- and since merchants have to pay for this system they always choose the cheapest fees which must therefore mean they choose the miner with the cheapest energy source". I'm not sure what this argument is meant to prove other than PoW chooses the most energy efficient way of doing PoW, but it doesn't prove the PoW isn't an energy hog.

This argument also explicitly ignores schemes such as PoS that don't have this massive power drain, and also ignores interesting schemes like PoC (Proof of Capacity)[1] that also don't have this power drain (apparently).

[1]: https://www.burst-coin.org/proof-of-capacity

I’m not going to spend a bunch of time reading this particular whitepaper, but not one of the three proof-of-capacity “mining” systems I’ve looked at are Sybil resistant and decentralized.

That's simply not true. When supply outstrips demand it's generally going to waste anyway.

Doesn't California actually pay Arizona to offload their surplus energy?

A few extra sunny days each year, due to lots of solar plants. Overall California imports more electricity than it generates in solar though:

http://www.energy.ca.gov/almanac/electricity_data/total_syst...

So the extra there is not really electricity you'd want to plan a crytocurrency operation around.

When supply outstrips demand in the power grid, the power is either sold elsewhere or you start shutting down plants.

Otherwise you'd ruin a lot of machines depending on either 220V/110V or 50Hz being on the grid.

If a hydroelectric power station produces 30 TWh per year, but demand including aluminum smelters is only 20 TWh, then there's 10 TWh excess.

This is use-it-or-lose-it. Should they just allow the river to flow and bypass the turbines?

This is a vast oversimplification, which only sounds plausible if you pretend that energy production scales linearly with demand. In the real world, if there's a plant producing more than its consumers demand, the reason for the excess capacity is to accommodate spikes and future growth. If you come along and build a BTC mining rig next door, that "future growth" has arrived sooner than expected, forcing the utility to build new capacity years ahead of schedule (presuming it's feasible to build it at all), resulting in significant price increases, their refusal to sell you as much electricity as you want to buy, or both.

The (amortized) cost of building out new supply is a major[0] part of the cost of electricity - this is why most big energy producers spend millions of dollars per year on energy efficiency incentives. Haven't you ever wondered why your power company will give you a $50 rebate on an EnergyStar dishwasher? Isn't it counter-intuitive that they would pay you to buy less energy, when they have excess? It's not because they're tree-huggers - it's because decreasing demand growth delays the day when they need to build a new plant to meet demand, which increases the profitability of the current plant enough to make those incentives cost-effective[1].

0: I can't find a good estimate and it varies by fuel type, but I rememeber an environmental engineer at a former job telling me it was about half. Look up "Levelized Cost of Electricity" for more info.

1: If you're not convinced, instead of demanding more details, I urge you to just stop and ask whether the proposition "There is a lot of excess energy production lying around which BTC miners can soak up without impacting everyone else very much" really passes the sniff test.

Hydroelectric is one of the oldest electrical storage systems there is -- you can store more electricity as gravitational energy by pumping the water back uphill, and then letting it flow back down during peak times.

There's a reason why hydroelectric plants and dams go together.

Very few dams have the capacity to pump water back uphill.

And they don't need it, because power-generating dams are generally only built in places that provide lots of downstream flow naturally, like the U.S. Pacific Northwest, or in places where a reservoir is already desired for other reasons (typically drinking water, navigation, and/or flood control).

Dams have the capacity to route downstream flow around some turbines to lower their generating capacity. It's not really accurate to think of that routed water as "wasted capacity," because that water would flow naturally even if the dam wasn't there.

... that reason being that dams are used to collect the water from rainfall.

With massive regional grids like what's present in North America, it's not just as simple as that. Someone on the other side of the continent could use your 10TWh excess and curtail their own fossil fuel use instead.

No, they can store it in some Tesla batteries.

Why won't keybase address requests for Monero?

I was wondering the same, why not add more options, just make it easy for people to get paid by whatever they want. Its also possible to simply just put a .txt on your public shared library and you can always list everything and anything you want there. Its just nice to see all that nice verification in the public profile nice and easy to see for everyone else.

Perhaps they'd be worried that their tool would be used primarily for narcotics trade. Oh wait, they already have zcash. Well, perhaps it's the redundancy between those two.

This doesn't exist right now, but theoretically a network like Ethereum whose tokens exist as state within Turing-complete contracts, could solve "counterparty redemption across forks" by simply allowing each contract to react to the fork "event" independently on each resultant forked chain. It'd be a lot like how the actual POSIX fork(3) call works!

Presumably, the default implementation of such a fork-event handler would have all but one of the contracts destroy themselves (and not in the common Ethereum sense of a contract "suicide", with the owner getting returned any held value; but instead with the contract simply blackholing all its value and state.)

I think this would create a bunch of security concerns and make the state of the contracts not immutable and would result in even more problems. Even though the contracts are deployed on a chain it they also take resources to execute (which is represented by gas) so at the end of the day if this occurred you would basically have one master contract with all the resources which would be a huge security concern since who is enforcing that people are honest?

Contract state isn't immutable. Or am I misunderstanding what you mean by "state" here? The storage slots in an EVM contract can be freely written to by said contract. That's how ERC20 tokens work—the balances of the token in people's accounts are simply storage slots, that get updated by the contract when the tokens are moved around. (Yes, actual slots. EVM arrays are weird; they actually expand out into the contract's storage-slot keyspace by hashing all the array indices together and storing the result at the slot identified by the hash.)

> they also take resources to execute (which is represented by gas)

...and so you'd need to pay to fork, proportionally to the number of contracts that wanted to react to your fork. Though keep in mind that the forked network on the "new" side would have a low hashpower, and so a low gasPrice, and so could afford the required gas quite easily (the base-case being one where the forking entity temporarily controls 100% of the hash power of the network, and thereby can just "pay themselves" the gas, just like when bootstrapping a new Ethereum private chain.)

The more questionable aspect is that the network "being forked against" would also need to pay. Somehow, you'd need to make it such that the whole of the network would "want" to execute such transactions. Mind you, gas just prioritizes which transactions go through; if the "right of way" of fork-event contract-input transactions is hardcoded, it doesn't matter how much gas goes along with it—the network will run them. You can even just add some code that means that the network can't make progress until those transactions are in. (I.e. that chain consensus will treat chains that had the same fork-event transactions appear "earlier" in them as better, so it's useless to put work besides inserting a fork-event transaction in, knowing that the branch you'll be creating by doing so will be outcompeted by one that just executed the fork-event transaction first.)

> you would basically have one master contract with all the resources

I don't see how this implies that. The fork-er doesn't get to decide what's happening inside the contract, on either side of the fork. The network, on each side, is just sending an event—"hey, the network forked, you {are/aren't} on the forked side"—to each contract that wants to know, and it's up to the contract to decide what to do with that information. Each contract is still a standalone program with its own private memory-space that nothing else can touch.

> If you want DB redemptions then you would include them in your trust lines

Now you just said "whatever Deutsche picks win" with other words.

  I've been convinced by Mazières and the Stellar team

As someone who's been in the cryptocurrency space for a long time I can guarantee you got swindled. Countless investors I have seen move to centralized "blockchains" due to buzzword powerpoint presentations and floating_nodes.jpg bootstrap landing pages.

This is no different than what current financial institutions do other than a new UI.

Are you saying this after having read up on Stellar[1] in particular or is anything other than "full" decentralization a deal breaker for you?

I think Stellar's model if Internet-style (as in the backbone network infrastructure) organic, federated trust relationships is the most practical and viable approach to decentralization that I have seen.

Organizations decide who to trust based on their relationships with them and individuals decide which organizations to trust for the same reason. That is how trust works in the real world, and for good reason. The problem is that the costs of operating at a global level in the current financial system are very high, which leads to centralized control.

Stellar will potentially allow many different types of new, small and innovative organizations to participate in the same network as larger more traditional institutions, with no restrictions for joining the network. Of course those small organization still have to compete for customers in the real world and the playing field is never fully level, but certainly opens up the game.

I personally just don't see the Utopian, fully-decentralized, f*ck-the-system future that a lot of crytpo-enthusiasts envision. It just doesn't mesh with the reality of how non-technical users operate in the real world. For example, right now the vast majority of US users purchase Bitcoin through Coinbase, because that is who they deem trustworthy. What I do see with Stellar is the possibility for greater innovation and greater individual access to the global payments network.

[1] https://medium.com/a-stellar-journey/on-worldwide-consensus-...

I have known 'Stellar' since its beginnings as Ripple. I have no expectations of changing your mind or obligation to convince you otherwise. Just thought I'd share my viewpoint.

I don’t understand this comment. It doesn’t seem to address any of the key technical points behind the Stellar project as it is actively used today, but instead tries to imply that the foundation is some group of fly-by-night scammers that have won over keybase by nothing more than a twinkle in their eye.

My impression was that Lumens seemed to be solving one of the legitimate problems of the world—the inefficiency of the SWIFT system for cross-border transactions—and appears to have a viable model for doing so.

I don’t see how whether or not it’s centralized makes it a swindle?

  the foundation is some group of fly-by-night scammers

Never said that. There are plenty of institutionalized and heavily trusted ventures on wall street that rake in billions and buy their way to the top.

This was my implication. I have known 'Stellar' since its beginnings as Ripple. I have no expectations of changing your mind or obligation to convince you otherwise. Just thought I'd share my viewpoint.

It's possible more than one system could replace SWIFT, but why would it be Stellar/Lumens who are still in the gate with their fork when Ripple/XRP seem to be already round the first bend with seemingly very large momentum in terms of interest, trials and actual production use by financial institutions?

How is Stellar still "in the gate," more than two years after deploying their decentralized Byzantine agreement algorithm?

Ripple has only just now, in 2018, published their decentralized consensus algorithm (Cobalt), which as far as I know is not even in production use yet, and doesn't provide optimal safety. (In settings where Cobalt is guaranteed Safe, SCP would be too, but not vice versa.) Their production network still uses a protocol that, by Ripple's own analysis (https://arxiv.org/pdf/1802.07242), fails to guarantee safety without >90% agreement on the UNL.

Yes, but perhaps your framework for approaching this is a little too old school?

When SWIFT was devised, the idea of having a singular system for resolving these transactions not only made sense but was (probably?) technically necessary. I think given where we are today, multiple competing protocols, each with their own advantages, may be viable.

Lastly, for finance, consumer choice is valuable: I like being able to Venmo my friends, autodeposit my landlord, slow mail my bills, and Apple Pay my retail purchases. I don’t send money overseas but I could imagine a similar bifurcation of solutions in this space, all with their own advantages.

While I generally agree, there is a difference between what bankers are doing atm with their ledgers and SOME projects in the private permissioned ledgers space. The difference is that they are not Byzantine fault tolerant, and distributed. If even just between each other, so there isn't the sort of robustness that you would have otherwise. It reduces a lot of overhead they have atm, with their ACH system. Which works, but it is not perfect.

An analogy I can be able to give, is banking is double entry book keeping. DLT's are triple entry book keeping, there is simply many things that their current ledger entries can't do. DLT allows their money to become commodity money, there is also a bunch of contracts that can be added on top of that. So main thing is banks could be able to potentially offer many more services than just verifying payments, at a much lower cost reducing the amount of employees they need. Make more offices or w/e else bankers do lol.