It's my right to be stupid
Plasma: Scalable Autonomous Smart Contracts
71–80 of 150 posts
Re: Plasma: Scalable Autonomous Smart Contracts
#72Earlier quoted context omitted.
I'm very glad to see this is being recognized more and more. Technically strong people can see it, but there are legions of ethereum fans who cannot.
Why does every crypto thread have these vacuous comments? Normally adding a "I agree" comment is met with "use the arrow". Maybe we could come up with a "HN law of crypto" that states all articles must be met with "paper money works just fine" or "just another tulip scheme". It seems asking for constructive criticism is out of the question due to the ideological motivations behind the criticisms.
I think it's because it is both hard to understand and hard to explain cryptocurrencies at the moment. It's like discussing email or social networks based on papers and ideas without really ever having seen it in action. We tend to get a bit aggressive or impatient when we find it hard to explain something.
Also, crypto skeptics realise that the crypto fans literally have money at stake so they are not unbiased. Maybe crypto skeptics are also a bit worried that perhaps there is something they didn't get. Perhaps they miss out on the next big thing.
Re: Plasma: Scalable Autonomous Smart Contracts
#73Earlier quoted context omitted.
Plasma is not for payments. It is a counterpart of Lightning Network, but for code. With LN you can do a lot of extremely cheap payments. With Plasma you can do the same for arbitrarily complicated code. Idea is - take some tokens to domain specific plasma chain, do your interaction with possibly byzantine actors, settle on parent chain when you are done. Today even timestamping is expensive in decentralized world. P…
> With LN you can do a lot of extremely cheap payments. The cost of transactions on a Lightning Network has yet to be determined, because no working LN (with merchants accepting payments) exists yet. We all agree than LN is pretty fast, but the ultimate test is cost per transaction. Allow me to remind you that if you want to send 1 BTC through 10 LN nodes, each of these 10 LN nodes need to bind 1 BTC in a payment cha…
Right, LN nodes will eventually become big speciallized hubs, with great BTC capacity to attend as many channels as possible. Each channel is a source of revenue for the LN node, so LN nodes will try to become as big as possible (both technically and BTC-wise) to cope with greater audience.
Think that in a LN-node the profit will be proportional to capacity of open channels, so its very probable that we will see very-big-BTC-LN-nodes appear to serve demand
The reputation of LN-nodes will play a very important to the users (as it already happens with BTC exchanges - do you use a unknown-fishy-exchange or do you use a big-known-stable-exchange ?), and so that will incentivize LN-nodes to avoid/solve problems with channels to avoid teardown-to-the-blockchain (which as you mentioned, is abnoxious to the user for its fee and lock-time)
Re: Plasma: Scalable Autonomous Smart Contracts
#74Earlier quoted context omitted.
By participating you're agreeing with whatever mechanism has been coded into the contract (which you can read for yourself). Obviously, you'd be stupid to participate in a contract that relies solely on twitter for resolution. But, for sports scores the contract could be coded to check all three of espn.com, nfl.com and abcsports.com (just for example). Same with the election results: usa.gov, cnn.com, foxnews.com, b…
Actually, it can't. In no existing blockchain-based smart contract system is contract code able to request random data from websites and act upon it. Websites as external sources are not deterministic, and determinism is necessary for the computations to result in the exact same result on any of the nodes that are part of the network in question. This also includes - and this is forgotten quite often - determinism ac…
this is actually incorrect you can verify a tls connection was made to a server and a particular output was given in that tls connection with oraclize it.
Re: Plasma: Scalable Autonomous Smart Contracts
#75Plasma is already the name of KDE's desktop interface. Reusing the name of an already known project is confusing.
[deleted]
Re: Plasma: Scalable Autonomous Smart Contracts
#76Plasma is already the name of KDE's desktop interface. Reusing the name of an already known project is confusing.
Yeah, I just click thinking that was something about KDE. Bad feeling give mes, someone that "steals" some popular opensource name for his business.
Yeah it really sucks when people do that. Glad it's not very often.
Re: Plasma: Scalable Autonomous Smart Contracts
#77Blockchain mentioned. Please explain me how it would ever work in the long run, if it scales extremely badly ?
The whole point of this is to move computation off the main chain and enable it to scale better.
Re: Plasma: Scalable Autonomous Smart Contracts
#78It's my right to be stupid
Not according to the SEC.
Re: Plasma: Scalable Autonomous Smart Contracts
#79Earlier quoted context omitted.
Let’s say we have 1,000 nodes in a network that does 1,000 transactions per second. If we shard the data, such that each node only needs to process 10 transactions per second — while trusting the remaining nodes on the other 990 transactions — how is this different from just reducing the number of nodes to 10, and having each node process all 1,000 transactions? In both cases the entire network only needs to process…
Because in the sharded example, only the shard suffers a break down, not the entire network, if the nodes collude. It also allows people to run smaller nodes on cheap hardware, this increasing the potential number of nodes in the network.
What’s the effect of a single shard breaking down? How many shards need to break down before it causes a problem?
Re: Plasma: Scalable Autonomous Smart Contracts
#80Earlier quoted context omitted.
Actually, it can't. In no existing blockchain-based smart contract system is contract code able to request random data from websites and act upon it. Websites as external sources are not deterministic, and determinism is necessary for the computations to result in the exact same result on any of the nodes that are part of the network in question. This also includes - and this is forgotten quite often - determinism ac…
this is actually incorrect you can verify a tls connection was made to a server and a particular output was given in that tls connection with oraclize it.
Which is just an implementation of precisely the oracle scheme I talked about. Introducing precisely the problems I mentioned: blockchain bloat, additional trust anchor which can never be 100% validated and thus destroys the idea of requiring zero trust in any particular individual person or system.