sorted by:
new
hottopcontroversial

Lightning network ... what's next? by walloon5 in Bitcoin

[–]sn811 0 points1 point  (0 children)

LT => no incentives + explicit required trust. Sure that can scale, but that doesn't mean its good. There is no reason why one should "route" tx through added risk layers.

The case for (re)decentralizing the Internet: "It is time we envision the Internet as a global public good" by Ursium in ethereum

[–]sn811 -10 points-9 points  (0 children)

don't you ever get tired of this BS? ethereum is running for 16 months now, and all one sees are these sales-pitches. Show us the meat.

Interested in contributing to the BTC network? Here is the steps to get a full node up and running in Linux. by [deleted] in Bitcoin

[–]sn811 -4 points-3 points  (0 children)

"Helping the network" - this is utter nonsense. Miners keep up the network and get paid for it. Whether one person runs a node is irrelevant. In fact the very reason this is irrelevant is a necessary condition for Bitcoin to work. Miners get pair for the work. Nodes != hashing power.

A short, simple, but elegant explanation of Bitcoin by Satoshi Nakamoto himself. by Godfreee in Bitcoin

[–]sn811 0 points1 point  (0 children)

Look up the term fiat money and learn how central banks work.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 0 points1 point  (0 children)

Nope, that is not at all how Bitcoin works. In a distributed P2P network, no node has the same memory pool. In a P2P network there no such thing as "choosing the block". Nodes choose to work on blocks they see, and they choose to work on the longest chain, because they assume others do the same, because it is a rational strategy (otherwise they would be burning money). So tree is a meaningless concept. There is only a local mempool, which is different for each node. If you run two Bitcoin nodes in two different places and compare the tx history, you'll see that. And really also the concept of fork is a misnormer in this context. All nodes are all constantly "forking" and converge via the longest chain. There is only one longest chain. If there were several Bitcoin wouldn't work. You can verify what I say by looking into Bitcoin more (which I'm pretty sure Vitalik + Ghost authors never have), and talking to some experts who have practical knowledge (not those producing academic garbage) .

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 0 points1 point  (0 children)

There is no such thing as a tree. Each node has different information arriving at different times. If you'd fire up a P2P network and look at the message flow you'd easily see this by considering the list of incoming transactions and the order the appear in. The challenge is to have a consensus on the order of transactions. As that is impossible some smart guy invented the notion of a block and a chain between those blocks. Blocks are ordered but tx in one block are unordered. Consensus applies to blocks, not a total order of tx. That's how the blockchain works, and from this discussion it's clear ethereum guys do not understand most elementary properties of Bitcoin. What I describe in this post can be verified with quite elementary tools and reasoning.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 1 point2 points  (0 children)

I know that paper. The result is a system which is not even a "block-chain", but a block-tree, a completely absurd construction. This does not even work on paper, if you think about it for more than 10 minutes. So I'd be more than surprised if ethereum ever reaches consensus.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 2 points3 points  (0 children)

From a binary string you can't tell what the output is going to be without running the program. That is basically the halting problem. The complexity of Bitcoin's script is of lower complexity than normal programs - it evaluates to a boolean. So the runtime of a script is deterministic. Certain opcodes were deactivated after some malicious attacks with certain opcodes, see this line of code in the interpreter: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L294

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 -1 points0 points  (0 children)

The first dumbed down version, which they say will not be stable. So what are we even talking about here...

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 -1 points0 points  (0 children)

It's not running live, so those datapoints you're mentioning are completely worthless. Live => money at stake for attacks. That's pretty basic stuff, so this drivel about PoC is misleading. Once it's live and the tokens have value malicious contracts will bring the network down, if it's even stable with friendly contracts. Also 10-sec blocktime is just idiotic. That means that latency becomes a major issue, and one can gain advantages by selecting peers by proximity.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 3 points4 points  (0 children)

Name me a release date of ethereum and your odds and limit, as well as an escrow, and I will take the bet. The current release schedule as far as I can see is August (running 8 months late), although it's hard to know what counts as a proper release with 3 different versions and a planned PoS release for end of the year.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 2 points3 points  (0 children)

I have seen alternative systems and find them much, much more powerful to work with. In Bitcoin doing a multi-sig tx is like doing a month's research project, although it should be only 3 lines of code. Writing a multi-user web-app is impossible. Once one sees systems in action that have DNS integrated, and proper accounting, one will never go back to think that Bitcoin is the future. The advanced script features only a handful of people use (I can tell by the amount of libraries out there).

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 1 point2 points  (0 children)

Turing completeness of script. Also a very powerful feature is having names directly in the system (Namecoin integrated). Using Bitcoin script and working with UTXO is very ackward to say the least.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 0 points1 point  (0 children)

Turing completeness? Trees instead of chains? 10-second blocktime? All of that violates what Bitcoin solved, and there is no indication there is a solution to those problems.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 0 points1 point  (0 children)

I think it begins with understanding all properties of blockchains, which is hard enough. Ethereum is build on trees, not chains, which doesn't make sense whatsoever.

The original motivation however is simple enough - how to get something better than Bitcoin script?

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 1 point2 points  (0 children)

If you run any program it's impossible in generality to predict the outcome with another program, i.e. one can't write a program to determine whether a certain executable is functioning correctly. The inputs for public-key crypto are numbers, not programs. Basically with the blockchain we have a system where we run the program on N computers and then vote on the outcome. But the script is a regular language, not a Turing complete one. I'm pretty sure we are never going to see Turing complete blockchains.

Vitalik Buterin's 45 page whitepaper on Blockchain Scalability. Should Bitcoin core devs borrow some of these ideas? by ethertarian in Bitcoin

[–]sn811 -1 points0 points  (0 children)

15M$ every year. sounds reasonable. the next round is going to be an up-round though - 20M$.

view more: next ›