|
Service is worthless since it doesn't protect customers from having their bitcoins stolen by the people claiming to insure them, but I'm sure they'll rope in lots of people who will regret it later.
|
|
|
|
Yes I realised that's what you meant the first time. But there is VAST, HUGE amounts of money to be made from having the power Ghash.io currently has to crush the price, even if they only have the power to utilize it ONCE.
Do central banks like Bitcoin? How much would they be willing to pay to crush it's reputation and price just before the bank bail-ins are announced and set it back 1 year +? How exactly do you propose that would play out? |
|
|
|
|
Maybe that wasn't as clear as it could have been.
If pools could grow indefinitely without consequence, then some of them, sooner or later, are going to try to monopolize the hashing power.
That is a bad thing.
If we assume pools operators and the miners who supply their hashing power are it to make money, then one very powerful disincentive for them to grow excessively is if their size causes adverse effects on the exchange rate.
That doesn't save you from an attacker with infinite dollars to spend who doesn't care about generating a positive ROI, but it does protect the network for lesser threats.
So when headlines appear about a pool getting too large cause a large selloff in the markets followed by rapid action by that pool to correct the situation it tells me the system is working.
|
|
|
|
|
If pools growing too large causes the exchange rate to crash that's a good thing.
Fear of their investment rapidly losing value is one of the economic incentives for pools to behave well.
|
|
|
|
|
"Hard fork" is a really bad term because it sounds unnecessarily scary.
It's a mandatory upgrade - Bitcoin has had them before and will again.
It kind of sucks to do them unplanned as a form of disaster response, but there's no reason to be afraid of them if they are properly planned.
Seems like it should go something like:
1) Write up BIPs for individual features that will require a new block version.
2) Write up a BIP to cover all the changes that will go into version 3 blocks and the upgrade plan including the conditions when version 3 blocks become mandatory.
3) Write code and tests.
4) Run everything through testnet
5) Release new software and wait for everybody to upgrade.
|
|
|
|
Personally, I'm surprised some of the other major pools didn't think of doing what CEX.io did earlier in terms of hosting hardware and allowing some to purchase shares in them. I mean, FFS, you'd think some of them would've noticed this earlier and gone "Hey, that seems like a good idea!" and implemented similar features in order to get more people involved with their own pools and help to limit the risk of a single pool having 51% or greater hashing of the entire network.
I seriously question the lack of foresight and initiative amongst the Bitcoin collective at times, I really do.
Within the next couple months CEX.io will have at least two competitors that I'm aware of, and that's just in Austin. |
|
|
|
The point of this topic was "super-lightweight" - and the easiest way to achieve this would be to have the "fee" explicitly included in the tx. Alan's original solution, on the other hand, solves two problems at once by making hardware wallets easier and also improving SPV security. I have no idea why the devs have no interest in this and why instead the topic needs to be changed to push other peoples ideas (why not create your own topics as I did?). Hopefully the answer is as simple as, "it would require work that nobody wants to do" and not, "if someone is found who is willing to do the work, their pull requests will be filibustered." |
|
|
|
|
It's a temporary problem - an artifact of the supply chain for ASICs still maturing.
Right now CEX.io can grab almost a quarter of the network hashing power because its competitors aren't online yet.
It won't be quite as bad when a "big miner" can only grab a single digit percentage of the network.
|
|
|
|
Unfortunately a lot of miners operated under an incorrect understanding of mining where they believe their income is proportional to the size of the pool that they are on based under a misunderstanding of mining as a race instead of as a poisson process and so they try to mine at the biggest pool. Seems like smart pool operators could take advantage of this incorrect understanding by raising their fees as their fraction of the hashing power increases. That would dampen the positive feedback effect of the dumb miners flocking to the largest pool just because it's the largest. Actually that's what they should have been doing all along. Price signals really do work better than rationing - when a pool is attracting more hashing power than it wants rather than block new connections it should just raise prices. |
|
|
|
|
I'm pretty sure when large retailers accept Bitcoin it's because they are getting pressure from their supply chain.
When Bitcoin really takes off in China you'll know it because suddenly out of nowhere you'll see Walmart upgrading the POS terminals to display bitcoin QR codes.
|
|
|
|
What if B and C are not mining pools but single miners?
How about instead of using some hypothetical situation that has nothing to do with reality, why not instead figure out how things actually work now and go from there? |
|
|
|
then why the recent hyper discussion about Ghash.io? The problem isn't ghash.io - it's cex.io They aren't a pool - they are a single organization that physically controls a huge percentage of the network hashing power, at least until a few of their competitors come online. |
|
|
|
Raw Technical Solution:All this because Satoshi made one little oversight in the OP_CHECKSIG procedure: the TxOut script is copied into the input being signed, but not the value. If the value was copied prepended to the TxOut script, then the offline system only needs to be given the 8 bytes, and it could securely present the correct fee to the user and sign it. If an attacker compromises the online computer and puts incorrect values into there to trick the offline computer, the offline signature will be invalid (because full nodes verifying the transaction will use the correct value the signature won't match). So the technical solution is simple: Add a new SIGHASH type, which I dub SIGHASH_WITHINPUTVALUE. This would have hashcode 0x10. This would be OR'd with the existing hash types. i.e. Currently all "regular" transactions are signed with (SIGHASH_ALL), now anyone who wants the benefit would sign with (SIGHASH_ALL | SIGHASH_WITHINPUTVALUE). It is compatible with the existing hash types. Analogy:Right Now: "I, the offline computer, sign this input to be sent to this address, no matter how much this input is worth" Proposal: "I, the offline computer, have been told this input is worth 13.28 BTC. This signature is only valid if that's how much it's actually worth" Doesn't this have even more significant implications that the ability to build simple, easy to secure, hardware wallets? Unless I'm completely mistaken the inability of SPV nodes to detect if a miner is inflating the currency is related to the output values not being signed along with TxOut scripts. A miner can create an invalid transaction that lies about the value of an input and use that excess input value as a transaction fee that the miner gets to keep. An SPV node can not detect this because it doesn't have a copy of all prior transactions, but if the value was signed along with the script would it not block this class of attack? |
|
|
|
|
Where is the song "Rudolph the Red Nosed Reindeer?"
|
|
|
|
Below is a hypothesis. Please prove me wrong. - You aren't really clear on how a mining pool actually works.
- You're not sure what a "51% attack" is, or what launching one involves.
|
|
|
|
|
It's hard to say that Bitcoins are "present" anywhere at all.
|
|
|
|
I'll just say this. Based on the stereotypes of your misgivings, there is a lot for you to learn about Bitcoin. And if you study long enough your mind will probably change. Not likely. Academia is hardly independent from the established interests which Bitcoin threatens. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." |
|
|
|
If they do indeed start allowing CEX.IO users to choose their own pool that will greatly improve the situation. |
|
|
|
If these arse-holes had a fucking brain they would self limited their hashing power to a sensible number like 35-40% of the network to ensure we don't have a problem like today as they creep onto 50%.
People are buying up mining shares on cex.io for above their NPV because they expect to profit from selling them to a greater fool later. That situation doesn't exactly create the best set of incentives for good pool behaviour. |
|
|
|
|
Show Posts
