buttershakes

9 ms·

31.
by buttershakes 9y ago
Well i consider trading a very valid use case, as well as simple peer to peer payment for all goods and services. How much transactional volume is Bitpay doing? 800,0000 isn't a big number, and certainly it will only represent a small
32.
by buttershakes 9y ago
Blocks aren't valid with double spends in them. You are saying the miner makes an invalid block by the rules in order to have a double spend transaction and then mislead the spv client with that information? I'm not making the arg
33.
by buttershakes 9y ago
I'm not sure why you think $800,000 per day is a lot. Compare that to daily volume for usage of the currency itself across all applications. https://blockchain.info/charts/estimated-transaction-volume-...
34.
by buttershakes 9y ago
SPV does absolutely check the block headers, which is all you need to do the proof. You can say that transactions could be omitted from the actual block chain, but not that invalid header data could be served that let someone believe they w
35.
by buttershakes 9y ago
1. You just need to connect to enough nodes that their is a statistical probability that you aren't being censored. 2. There are already alternatives which have better censorship resistance than Bitcoin, limiting the block size does li
36.
by buttershakes 9y ago
You are ascribing to the Bitcoin core narrative of a bunch of freedom fighters who are building a decentralized future of freedom, but that narrative does not hold water. First off, Gavin, Jeff, Mike Hearn, you know the guys that have spent
37.
by buttershakes 9y ago
Why do you say it's an attempt to make Bitcoin more efficient? It's essentially exactly the code base of Bitcoin core with some very minor changes including a block size commitment in the future. Seems pretty clear that it is abou
38.
by buttershakes 9y ago
You seem to be missing my point. I can fork Linux right now, make some random changes and I have a fully functioning equivalent system with those minor changes. I can fork Bitcoin right now, make some random changes to the consensus code, a
39.
by buttershakes 9y ago
It would take years for the difficulty to adapt to a 10 minute block time if the hash power dropped that much, there is a limit per two week adjustment period. More than likely the code would have to be modified to accommodate a rapidly dro
40.
by buttershakes 9y ago
The taking a little while to adapt is because their is less hash power, which means it takes longer to find blocks which means the remaining hash power will have less blocks for many many weeks. This means their expected return is lower, no
41.
by buttershakes 9y ago
You are making the mistake of equating Bitcoin development with other open source projects. It's just not comparable to Gnome, Linux, or any other open source development. If I don't like the gnome developers I just don't ru
42.
by buttershakes 9y ago
I have taken sides, but against the general core development process and the corporate interests that are permeating it. Yes, blockstream is not core, but they have exerted a tremendous amount of influence on the team and direction. In addi
43.
by buttershakes 9y ago
That's not what it means. You are right that those clients would begin rejecting blocks, but you can be sure that when customers are calling them asking why their transactions aren't being validated that they will switch. It'
44.
by buttershakes 9y ago
You just need to look at results. We have a fragmented and fractured community. The guy tweets non stop in some ideological holy war. They were even called out by Fred Wilson at Consensus for basically not delivering anything of value, and
45.
by buttershakes 9y ago
I've used this, it's an awesome project, but it's basically just pipes all the way down. I'm thinking of something closer to a NIF. I think Saleyn's c++ node code might be the closest thing for a lower level languag
46.
by buttershakes 9y ago
So if a huge number of nodes are Segwit2x capable, and the miners are mining Segwit2x blocks with the majority of the hash power, companies are going to stay on a less secure chain that can be attacked by the majority so that they can have
47.
by buttershakes 9y ago
They are using the same hashing algorithm with different consensus rules. That's exactly the issue. They are fighting over the same pie because proof-of-work is what defines Bitcoin.
48.
by buttershakes 9y ago
The only support it needs is hash power support. That's it. If enough of the hash power can be pulled into it, then it's game over for a minority chain. Running nodes costs almost nothing which means the network can be flooded wit
49.
by buttershakes 9y ago
You basically can do exactly that. Unless the companies involved want to run on a minority chain with much less hash power, which means they are exposing themselves to a 51% attack as soon as their difficulty drops significantly behind the
50.
by buttershakes 9y ago
This is false. Bitcoin is a consensus system, and the default client for better or for worse has a stickiness that doesn't exist in normal open source software because of this group consensus. So there is definitely a measure of contro
51.
by buttershakes 9y ago
This is a fight for control of Bitcoin. It is business interests on both sides fighting for a position of authority. SegWit2x is an attempt to remove control from the core dev team, which while technically strong is full of zealots with que
52.
by buttershakes 9y ago
Regardless of the secure computation done during the ceremony at the end of the day there is a degree of trust in the founding participants of Zcash. I think given the people involved, and that they are all essentially security zealots with
53.
by buttershakes 9y ago
I really wish there was a way to do inline optimized code, i.e a gen_server that transparently wraps another language without having to get into nif / external servers. Basically an abstraction that hides all of that cruft and builds o
54.
by buttershakes 9y ago
Well, they do scale. It's just a question or how much they scale. A practical perspective says we don't need to scale to VISA levels right now, we just need to slowly increase the block size to encourage adoption and new users whi
55.
by buttershakes 9y ago
It's unfortunate but as a consensus driven system it is much different structurally than say Linux. I can fork the Linux code and run my own version and nobody cares and it still has utility (for me), but Bitcoin as a whole requires a
56.
by buttershakes 9y ago
This is probably exactly what will happen, because the chain will not be able to support transactions directly in quantity, and so we end up with a plethora of middle men who are responsible for opening and maintaining payment channels. Tha
57.
by buttershakes 9y ago
This will go down as a massive failure in governance. The Bitcoin core guys have completely created this situation by taking a hard liner stance based on a non issue. Committing to a 2 megabyte hard fork 2+ years ago would have averted this
58.
by buttershakes 9y ago
It's very far from being able to scale to where it needs to. I think it remains to be seen if the system can be transitioned to a highly scalable one, it seems to me that we need to think from the ground up how to achieve the scale nec
59.
by buttershakes 9y ago
The reduction is capped at 33%. It doesn't redeem any amount past 3 mistakes. The reason being is that I didn't feel comfortable reducing the keyspace by more than that, although given the size of the keyspace I could have probabl
60.
Show HN: Lost Ethereum
18 points by buttershakes 9y ago|2 comments

More ›