<snip> Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.
When the difficulty changed, the first machine in my group to generate a block was the slowest one running the stock client (800 MHz E-machine) and it hadn't generated anything in over a week itself. So I guess every little bit helps, that's so many are interested in getting this to work on their machine. |
|
|
|
Thanks very much for the extensive and informative reply. I do not disagree with the points that you made, but I also don't believe it invalidates my fundamental point: it is not inherently necessary for a digital currency such as bitcoin to require as much energy input as bitcoin does. A digital currency that offers bitcoin's behavior at a "lower cost" of energy overhead of the currency and transaction system has a competitive advantage. The digital currencies that will win and become standards, I believe, are the ones that offer the most value-added on top of the costs of running the system. Of course, there is room for many currencies - we already have a multiplicity - so it is not necessary for Bitcoin to become the "one true money" for it to succeed, but I believe the current minting policies will be harmful to its growth and adoption long-term. Much of the utility value of bitcoin resides in the work done to establish the security and reliability of the system - accomplishing that work with a smaller energy input would seem to be beneficial.
I think though you are comparing apples to oranges. The coin generation is for currency creation. You don't need to generate any coin to use the bitcoin system. You can purchase it from many market sites or get some donated for free from other sites. The current minting policy is what makes it useful because a digital currency where everyone has unlimited amounts (or large starting amounts) just causes unnecessary starting inflation. The overhead for the currency is by design, otherwise if someone creates an *easier* system, it will be quickly abused. Since you can't make everyone play fair, you create something where it's nearly impossible to cheat by using math. To make cheating expensive instead of "easy" is where this system works. If it's more profitable to generate coin than to cheat it, guess which one everyone will go with? |
|
|
|
If someone takes the ip address method to the next level it really should be changed to provide some kind of security, like agree on a password/address or something ahead of time. Sending to an address and creating the key automatically provides no authentication and there's no recourse if it went to the wrong place; the intended receiver is unaware you even tried to send anything. It is trivial to proxy it and MITM that kind of activity and with the value of bitcoins rising it might just be worth doing eventually.
What if it had a flag for "secure/unsecure" transaction type, where one can have a password for static IP to static IP transactions and an unsecure mode that works like the default IP sending the GUI uses? I consider the ip address sending a local testing feature more than a production level feature in the way it is currently implemented. One possibility that could work is if the receiver provided a public key (address) to you first and you used a combination of internet address and public key. It is not as convenient but the alternative is to just send it to the ether and hope nobody grabs it before it gets to your target. If anyone has used liberty reserve or something similar you know it is certainly not convenient to log into and such, but when it comes down to a choice of losing your money or dealing with an inconvenience I think most people would prefer the latter.
If the address based transactions types could send the comments/from field like the direct IP to IP, that would be another reason not to really use the feature (except for testing)  |
|
|
|
I believe that the amount of energy input required to the bitcoin economy represents a serious obstacle to its growth. I think in the long-term, transactions may be even more serious than minting in this regard, but I will for the moment discuss minting because it is more precisely bounded and defined. The idea that the value of bitcoins is in some way related to the value of the electricity required, on average, to mint a winning block is generally accepted, but the precise nature of this relationship is contentious.
One argument is that anyone who chooses to generate coins is actually making the choice to purchase bitcoins with electricity/computational resources, and that because some/many people are in fact making that choice, bitcoins have at least that much "value" to the generators, who can be assumed to be maximizing their utility. A contrasting argument is that cost of production is different than market value, and the most objective measure is the current market conversion price to a more liquid and widely traded currency such as the US dollar.
My only counter is that it will seem that way to a first time user, because they have no bitcoins at all. But there are a possible 3.6 million bitcoins out there plus a member here runs a site that gives away free bitcoins so people can experiment with the system. The amount of actually energy, if you break it down, is only that of the PC itself. When you consider how few watts a processor runs to get a block where each 50 BTC block is worth about $3 USD, that's much more than the electricity cost it took to create it. Right now, you can generate BitCoins and sell them for more than it cost the electricity to run the PC to do it unless your electrical rates are the highest in the world. The only reason no one does is the scale of economics that would be required to make it profitable. My contention is that both of these arguments miss the point and the real problem, which is the fundamental perversity of wasting large amounts of energy and computations in generating the winning blocks for the minting process. The minting process exists because of the necessity of actually "printing" the currency, and certain desirable properties of crypto-math for making the currency's behavior predictable. The fact that the current minting process requires a large energy input of computational work is highly unfortunate and has the perverse consequence that bitcoin may actually be "destroying wealth" in the sense of wasting energy producing a digital object worth less than the resources invested in it.
The same can be said about gene folding or SETI since a ton of CPU time and electricity often does not reward the individual user of the their client software. It's the collection as a whole that rewards everyone in non-monetary ways (find cure for cancer, find aliens, etc.) As is often pointed out, a currency does not necessarily have, or need to have, any inherent value - a medium of exchange is a useful tool and can have value purely as a consequence of social convention. The cost of production of bitcoins in electricity consumed represents a waste, a "thermodynamic burden" that the currency has to carry. Consider a hypothetical alternative digital currency called "compucoin", which purchases cpu cycles from nodes on the network. The market value of this currency would converge very closely with the cost of electricity required to generate cpu cycles. Instead of costing cpu cycles to mint, the value of the cpu cycles the coins could be exchanged for would create a rational basis for the currency's value and integrate it with an existing market. I imagine that alternatives to Bitcoin (many of them probably sharing a lot of Bitcoin's source code) will inevitably emerge and Bitcoin's current minting process makes the currency "expensive" in terms of energy input. I believe this places it at a competitive disadvantage to other currencies and can only hinder its widespread adoption and long-term value.
Unless electrical rates go up higher than the value of BTC, there will always be people willing to trade out CPU resources for it. Currently, cheap VPS farming has a return on BTC generation, though not very much. The other benefit is that the generation rate tries to remain constant, so it's not always going be hard to generate BTC if less and less people decide to do it, the difficulty goes back down. |
|
|
|
Should have mentioned in my first post, but everyone remember, during this last change, 0.3.6 came out and doubled the hashing rate... so that really just reflects the increase in efficiency of the new version.
A very good point, I hadn't thought of that. So if that's true, everyone should generate at about the same rate they did before since the bar was raised for everyone by everyone? |
|
|
|
bitcoin@s7:~$ ./bitcoin-0.3.8/bin/64/bitcoin getreceivedbylabel mylabel minconf=10
error: type mismatch
bitcoin@s7:~$ ./bitcoin-0.3.8/bin/64/bitcoin getreceivedbylabel mylabel
0.000000000000000
or I did not understand the format of command? Should be bitcoin getreceivedbylabel "Your Address" 0Your label must be in "" if it has a space in it and the next sytax is the minimum number of confirmations to count towards the total. So if that command spits back 10.00.... for example and you changed the last number to 4000 (meaning, only count transactions that have 4000 confirmations or more) then you might get back a 0.000... for example if you have no transactions with that many confirmations. |
|
|
|
Switch to sending payment to IP addresses. They don't have to be static for this purpose. If you happen to miss it, too bad. Any unrelated person who happens to be at the requesting IP address probably sees tons of other random connection attempts from the Internet at large anyway.
Can't do that with the current state of the software  |
|
|
|
IMO that's good news. It shifts the emphasis over to adding value to the currency, rather than minting.
If you ask me, it's way to early. We only got a few thousand users and almost nothing to "buy" for coins, why would someone want to "add value" to it? Way more than a few thousand I believe. I just shutdown a server farm last month of 300+ machines and the difficulty continues to climb, so there are a lot more people using it than what we see reflected at the forums here. If you run a supernode (not recommend unless you have gobs of CPU and bandwidth), you'll get a glimpse of how many machines are out there with the client running, my last count was 3,700 on one of mine. |
|
|
|
[edit] I see it will show generated coin, so that is useful actually. Also, the current getreceivedbyaddress & getreceivedbylabel seem to be buggy in which transactions they show to begin with.
Buggy, how? Maybe they are just confusing, like they were to me, initially? getreceivedby* are by-address or by-label totals, not individual transactions. listtransactions was created while trying to implement web services for bitcoin. The only alternative I can see for tracking transactions, outside of listtransactions, was watching individual bitcoin address totals. getreceivedby* is not reliable, in that regard. Confusing because I didn't know it was just "amounts" and not transactions. So in that regard it's still buggy because I have a system that I did a bunch of test transactions and yet none of the correct totals show up in the summary. If you run the GUI in server mode, you can throw server commands with it running at the same time to compare output and never match the GUI unless there is more detailed description about what output the function is suppose to give. |
|
|
|
Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.
Only if the "dust" is combined back together and confirmed deeply enough again only then can the dust space be dropped.
Does sending 0.1 BTC a million times also create a single transaction? Where is the line when it goes from a single transaction to independent transactions? Can the line be moved down slightly? Any bad side-effects if it was? |
|
|
|
Ah ok, does this new function also list individual transactions from IP to IP transfers? I took a glance at the source to get a rough view of what it's showing, didn't know it got into that much deeper detail.
It should present a list very similar to the GUI-presented display. Ah ok, good to know. When I read over this topic, I saw some "example" outputs that didn't look that much different than what I was use to seeing, but now I see how useful feature really is, so it certainly has my vote. |
|
|
|
|
Aren't the JSON-RPC commands the same as the command line, just ported over the http ? Both would return the same problem I believe.
|
|
|
|
It's not implemented.
It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.
Well I guess it's time it got some attention Dang, that's two things I have to put my list now, good thing it's open source!  |
|
|
|
I have to agree with Satoshi, other than the extra field of "credit/debit" how is this different than getreceivedbyaddress & getreceivedbylabel? Can someone explain it to me better?
It lists transactions while the getreceivedby* functions return the sum of all transactions to that label or address. There's no reliable way to see individual transactions using the getreceivedby* functions. Ah ok, does this new function also list individual transactions from IP to IP transfers? I took a glance at the source to get a rough view of what it's showing, didn't know it got into that much deeper detail. |
|
|
|
What are you needing to use listtransactions for?
The reason I didn't implement listtransactions is I want to make sure web programmers don't use it. It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.
I have to agree with Satoshi, other than the extra field of "credit/debit" how is this different than getreceivedbyaddress & getreceivedbylabel? Can someone explain it to me better? My only beef with *all* those function calls is that direct IP to IP payments are never shown. As it is right now, if I send a payment via IP to IP, I can't find it with those commands. I can see the balance is right, but I'm not sure where it came from because neither command will show me any info about the transaction. If listtransactions (or getreceivedbyaddress & getreceivedbylabel) could list IP to IP transactions, that would be useful. [edit] I see it will show generated coin, so that is useful actually. Also, the current getreceivedbyaddress & getreceivedbylabel seem to be buggy in which transactions they show to begin with. |
|
|
|
All I have is a CentOS bitcoind that was compiled with glibc 2.5, so it won't work on the system you listed. All I can say is that it took me all day to figure out the compiling issues for CentOS 5.5. Perhaps I should start offering compiling solutions for various Linux distros with BTC as the cost?  |
|
|
|
|
What version of Glibc are you using?
Goto the console and type "ldd --version" it should tell you what your OS is using, post it back here. I might have a compile that works with yours.
|
|
|
|
|
That's a really good idea, just make a queue system with a simple "click to approve" button.
I don't know how much traffic the faucet site gets though, might not be practical from a human standpoint, but I don't often see the faucet that far below 500 most of the time.
|
|
|
|
|
This has been going on for a while I would say. I noticed that when I would donate BTC to it, I would check the site a few minutes later and it would be back down below 500 again very quickly (but not further down since it appears to stop after it reaches below 500)
I'm afraid with how the nature of Bitcoin works, even if you narrow it down to IP address, Bitcoin Address, cookies, browser string, etc. someone can still fake/change all of those to drain it.
I think your recommendation of 0.50 with it being reduced to the 0.05 when it hits below 500 BTC would work better to deter this kind of thing. Also, a rate per hour limit (because someone with a botnet could have all of them descend on it and empty it even at 0.05 a piece just for kicks)
It's obvious from your logs, the guy/gal was just renewing his IP address, generate a new bitcoin address, refresh the page, copy/paste new bitcoin address, send 5 BTC; rinse and repeat.
|
|
|
|
What exactly is this 'dust spam' that this 0.01BTC transaction fee "solving"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.
There are builds that remove this limit, mainly for testing right now, I think that's why it's disabled until it can be tweaked a little more. |
|
|
|
|
Show Posts
