5 ms·

Blog author from Keybase here. Always game for a Hacker News discussion! There's a subtle point I cut from my post for simplicity reasons, but which feels perf

• zitterbewegung 9y ago
  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?
  • nebulous1 9y ago
    > 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.
  • huslage 9y ago
    Electricity consumption is not an "artificial scarcity"
    • zitterbewegung 9y ago
      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.
      • rickycook 9y ago
        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
• ploggingdev 9y ago
  Have there been changes to Stellar to address the topology trust issue that `nullc brought up in the linked thread?
• shivpat 9y ago
  Why won't keybase address requests for Monero?
  • vesak 9y ago
    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.
  • saintbellarmine 9y ago
    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.
• staplers 9y ago
  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.
  • deleted 9y ago
    [deleted]
  • ordinaryradical 9y ago
    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?
    • diakritikal 9y ago
      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?
      • ordinaryradical 9y ago
        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.
• beaner 9y ago
  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.
  • lalaland1125 9y ago
    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.
    • panarky 9y ago
      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?
      • mynameisvlad 9y ago
        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.
      • JustAnotherPat 9y ago
        No, they can store it in some Tesla batteries.
      • cbhl 9y ago
        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.
• redspectre 9y ago
  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.
  • theptip 9y ago
    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.
  • mazieres 9y ago
    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.
• derefr 9y ago
  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.)
  • zitterbewegung 9y ago
    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?
    • derefr 9y ago
      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.
• xorcist 9y ago
  > 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.
• drdeca 9y ago
  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.
  • oelmekki 9y ago
    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.