why do you need to run a full client? there are many good alternatives.
Because I do. |
|
|
|
if you cannot properly/easily compile a client you should not be running an alt coin or developing a coin unless it is just for your own instructional purposes. The best way to learn is to learn to compile bitcoin first. Then learn to compile litecoin. These are the basics.
This attitude is why PGP was such a failure and why we don't have email encryption as standard.  |
|
|
|
And what about the HUGE blockchain size?
As time passes, it becomes more and more difficult to handle the blockchain.
Bitcoin have been up and running since 2009.
That is more than five years!
It is currently 34.5 gb, and it was 10 gb less 6 months ago!
This is a 25-30% increase in six months!
I must echo this. I am not impressed with the platitudes such as "storage is cheap". As of writing, Bitcoin Core requires 40GB. I have a several laptops with varying space of about 20-40 GB spare so it will no longer fit on any of them. They all sport SSDs so huge drives are not "cheap" and if you expect me to go back to mechanical drives just to run this one piece of software; you are insane. The spare space is perfectly adequate and has been for a few years. I tried moving it to a NAS which has 10 TB of storage spare. I had to use a symlink to fool Bitcoin Core because it only uses a fixed local directory. Once I had managed to convince it that no, it isn't really on another drive, it was extremely problematic in that it took hours to "verify" when starting the application and that's before getting to updating the blockchain. There are many small accesses which are horribly inefficient trying to verify. On some occasions it borked and refused to continue because it somehow corrupted during the verify. The NAS solution is currently not really viable. Bitcoin is suffering from similar problems that PGP suffered from. Nerdy software that is rigid and inflexible and unusable for many. You can, of course, put all your coins in an online exchange but you might as well keep your dollars in the bank-it's the same thing. If Bitcoin Core can be run from a laptop, Raspberry Pi or even a mobile phone with, say a gig or two of working data but the vast majority of the blockchain reside on a remote NAS. Then it would become workable for me and probably most other people too (yes I do want full nodes). If it can reside on a remote NAS and accessed at WiFi rates, even better. This all presumes that the size is a necessary evil so the approach is to be able to split the blockchain into historic and working data sets for the blockchain with lazy updates back to the NAS. At the moment the software is like this: http://www.freakingnews.com/pictures/25500/Ruben-Studdard-25987.jpgI'll leave the rant about not having a torrent client built in for the peer to peer distribution of the block chain for a later post. |
|
|
|
In most wallets you set the fee per kb, not per byte, and then the calculations are being made from there whether the fee is rounded up to kb or set per byte. I highly doubt OP meant he was setting 500 satoshis per byte. I'm pretty sure he was setting it per kb and that's way to low. I insist that he should set it to 0.0001 per kb (or the equivalent per byte but I really don't think his wallet is asking per byte). Anyway as I said it would help if OP mentions the wallet he's using. I you meant something else with your high-priority TX link I didn't understand you. I should have mentioned in my previous post. Sorry! The recommended fee is 0.0001 BTC/1000 bytes. If you convert 1000 bytes to kilobytes, you will get 1KB. So the fee is per KB not per bytes or you can say, the fee is per 1000 bytes. Saying fee is per byte is wrong. Since 0.9.x Bitcoin core release, the default fee has been set to 0.00001BTC/1000bytes. Fees/1000bytes help in the ranking of transaction but it shouldn't matter if the priority is high enough. *1KB=1024byte but 1kB=1000byte. In this case, it is kB. Ahem. 1KB=1kB=1000 bytes. 1KiB=1024 bytes Search Google for "Kibibyte" |
|
|
|
All nodes verify transactions and relay them to other nodes. While miners are the only ones who create new blocks of confirmed transactions all nodes verify everything.
Thanks for clarifying. Does that mean only miners are able to put blocks into the block chain and clients are merely signatories that they have done it correctly? |
|
|
|
|
There is no bandwidth throttling in the current clients (there should be IMHO). Since it seems only miners can verify transactions (someone correct me if I'm wrong) there is no point in having the bitcoin app running unless you actually want to do a transaction.
|
|
|
|
Bitcoins can be tracked through the network. Identifying an individual is dependent on out of network information, however. So all you peeps with a bitcoin address in your signature-beware! An Analysis Of Anonymity |
|
|
|
How about I do that easy fork, then we test the hard-disk thing and decide whether to adopt it later?
I can do the easy fork in probably a day.
Better still. Post a link to the source so we can inspect and build it. |
|
|
|
That is not entirely correct (partially yes). Difficulty will scale up accordingly. But I do agree the ASICs hardware cost now far exceeds the electricity cost. This may change as ASICs are converted to IC chips that are mass produced.
My design uses hard-disk space, which is much more reliable to predict. We won't have these phase-shift changes causing miners to waste capital in a direction that becomes obsolete. The Moore's Law for hard-disks is very predictable.
I want miners to be healthy. I want every user to be able to mine some. In the design of a P2P currency, you can't neglect a part of your ecosystem. Investment requires predictability.
You are missing the point. Difficulty is irrelevant. It just takes longer to glean bitcoins as difficulty increases. As the electricity is free (and you have already sold some bitcoins to recoup the initial outlay), you can just leave it switched on without incurring electricity costs. The issue becomes is it more profitable to mine bitcoins or sell the juice to the grid. But this is an aside to your main points (it was just a comment to the poster about electricity). More in line with your OP........... I find the 51% very troubling. As I pointed out in this thread a 51% hashing power takeover has already taken place and was been proven to be effective. In this case the "cartel" was the bitcoin community, but it might not have been. |
|
|
|
You don't realize that investing in PV is economically worse than renting electricity from the utility.
You don't realize that nobody can manipulate electricity prices if you produce it and in the long term it's cheaper in some parts of the world. You don't need mains electricity anymore with the new ASICs. 4 solar panels will run it so as long as you can recoup the ~$3500 outlay in the medium term. (A lot less than the outlay on GPU rigs and no running costs). When/if bitcoins become unprofitable, you can then just sell juice back to the grid. |
|
|
|
|
Aww. MtGox Websockets down again
|
|
|
|
I had my doubts originally, but it looks like MtGox offloading US and Canadian customers to Coinlab was a smart move. |
|
|
|
|
Woohoo.
Up and running again
|
|
|
|
|
The websocket server has been unresponsive all day. I cannot ask on the thread (being a newb and all that).
Any ETA until it's back up and running?
|
|
|
|
They'ld throw twenty million+ dollars away? I doubt their shareholders would think it wise.
Well. a) It's not their money they are playing with (unless they use their bonus). b) 20 million is chicken feed when you can create fiat. c) Market manipulation would make it worthwhile (if that is the possibility). We all know the other markets are manipulated using high frequency trading. Bitcoin "could" be the next "wheeze". I think the difference between now and, say, a year or so ago, is that it is now on the radar and the market has been shown to be fairly resilient. Couple that with a deep mistrust of the current banking system and the sector is seriously looking at how to exploit BC. I have looked quite a bit at the technology and really like it (especially the lesser known transactions for escrow etc). It's just the 51% that causes me concern. Especially as it was effectively what was used to address the forking issue. |
|
|
|
What is to stop a government or even an institution (read bank) putting 10,000 asic miners in a building and subverting the network to their new chain? Nothing. There are some suggestions about what to do in this case and how to avoid the attacker chain to be used by the clients but well, so far nothing serious. Technically a 51% attacker can rebuild the chain from where he want and do what he want with all the transactions, keep them or reject them. Well. According to the Wiki An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
Prevent some or all transactions from gaining any confirmations
Prevent some or all other miners from mining any valid blocks
The attacker can't:
Reverse other people's transactions
Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
Change the number of coins generated per block
Create coins out of thin air
Send coins that never belonged to him
It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. It's impossible to change blocks created before the last checkpoint.
Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent. I suppose what I am not comfortable with is the line "it is expected that no one will attempt it". I know of some people in the banking sector that would do it just for laughs if it became mainstream and, if you can "print" fiat, cost is no problem (hell, how many ASICS does a bankers bonus buy!). |
|
|
|
|
Hi all.
I've been on the periphery of bitcoins for quite a while and must admit, whilst quite enthusiastic I have wondered about the 51% since the beginning. My understanding is a little sketchy in places, so please point out any incorrect assumptions/analysis.
On March 12th 2013. A bug was revealed in the 0.7 software which caused a hard fork in the bitcoin chain between 0.7 and 0.8 clients. Whilst the system is designed to do this so that new forks (read, new currencies) can be created, in this instance it was undesirable. The bitcoin gurus recognised the issue rapidly and, as an excellent example of on-line collaboration between devs and traders/miners, the issue was rapidly resolved. My question, however is in the way it was resolved.
During the height of the issue, there existed two divergent forks. The 0.7 fork could be assimilated by the 0.8 clients, however, the 0.8 fork could not be assimilated by the 0.7 clients. Since the 0.8 fork had most of the hashing power, the 0.7 fork could never catch up so that it could be assimilated into the main block chain. The response to the issue was that, since most of the hashing power was on the 0.8 software, a temporary switch to majority hashing on the 0.7 version was conducted by asking the major players to downgrade their software (i.e. 51% of the network switched to the 0.7 fork.). This enabled the 0.7 block chain to overtake the 0.8 one at which point the 0.7 chain would become the main chain and the 0.8 clients switch over to it (presumably all the miners then immediately upgraded).
This is troubling though. If it was fairly straight forward for a few individuals to "agree" to switch over to a different fork and effectively take over 51% of the network (albeit in a good cause) . Then what of a government backed attempt to do the same. What is to stop a government or even an institution (read bank) putting 10,000 asic miners in a building and subverting the network to their new chain?
More over. Can anyone explain (in laymen terms) if that were to happen, what would be the effect on the current bitcoin chain and clients, the rules that the current clients abide by and the implications/impact of the 21e10^6 limit?
If it has already been answered elsewhere, my apologies, However I would appreciate some some links since I do not know my way around the board as yet.
|
|
|
|
|
Show Posts
