Bitcoin Forum
May 06, 2024, 11:05:56 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 [111] 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 ... 195 »
2201  Bitcoin / Pools / Re: [320GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: March 19, 2012, 06:16:50 PM
I am testing my central p2pool node, finally on a real linux machine :-)

Strangely, p2pool reports way-too-low hashrates. I mine with constant 290Mh/s, all day now. P2pool says:

Quote
2012-03-19 19:02:01.592058 New work for worker! Difficulty: 0.107541 Share difficulty: 667.763165 Total block value: 50.028282 BTC including 39 transactions
2012-03-19 19:02:02.060129 P2Pool: 17395 shares in chain (17175 verified/17399 total) Peers: 10 (0 incoming)
2012-03-19 19:02:02.060293 Local: 11354kH/s in last 10.0 minutes Local dead on arrival: ~15.4% (2-40%) Expected time to share: 2.9 days
2012-03-19 19:02:02.060357  Shares: 0 (0 orphan, 0 dead) Stale rate: Huh Efficiency: Huh Current payout: 0.7961 BTC
2012-03-19 19:02:02.060422  Pool: 314GH/s Stale rate: 7.1% Expected time to block: 5.7 hours

I may or may not find a share every few hours. But it is in the two-digit Mh/s range all the time, thats what bugs me.. Cant be the dynamic difficulty adjustment, since it says "kH/s"? Lost here..

--version:
6b4c15a

Ente

edit: silly smilies in quote

Yeah, that is pretty bad.  To me, it looks like your miner is using your CPU and not your GPU.  Is your miner reporting normal speeds?
2202  Bitcoin / Pools / Re: [320GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: March 19, 2012, 06:12:13 PM
Would "Fuck you" be less disappointing?

Forrest has spent hundreds of hours to make it possible for idiots like you to participate in a decentralized pool and still get regular payouts.  And you say that he is exploiting people by having a default donation of half of one percent that can be changed by anyone that bothers to read the documentation provided?

Let me say it again.  Fuck you.  By creating and developing this incredible software, he is helping not just you, and not just all p2pool users, but the entire bitcoin community.  You should do the decent thing and apologize for you ridiculous accusation.

..tempted to push the 'ignore button' on you, which would be the first time here..

Ente

Heh.  Don't threaten, just do it.  Won't bother me in the least.

But if you disagree with what I've said, rather than just thinking that I'm an ass, please say how and why.  I've been wrong before, and I've admitted it, and even apologized a time or two.  I don't think that'll happen this time, but maybe I actually was out of line.

But so far, Nim has made an outlandish and hurtful accusation against someone that has done more good for this community than probably 99% of us ever will.  However harsh and rude my delivery, I think my point still stands.
2203  Bitcoin / Pools / Re: [320GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: March 19, 2012, 05:29:47 PM
Some people have started using the default donation as a way to bad mouth P2Pool.

Obviously it's easy enough to disable if you bothered to read the wiki. Still, I think it would be better to make the donation opt in instead of opt out.

Don't get me wrong, I think forrestv deserves the donation (and more) for all his work on P2Pool, but maybe it would be best to default the donation to 0 in a future release?
Seriously?  People have a problem with half of a percent that can be changed to anything else, including zero, with absolutely no effort?

Screw 'em.  Leave the default where it is.
The fact that you guys take criticism as bad mouthing is not a good sign. You should see feedback as an opportunity to improve and not just say "screw 'em". This response is very disappointing.

Would "Fuck you" be less disappointing?

Forrest has spent hundreds of hours to make it possible for idiots like you to participate in a decentralized pool and still get regular payouts.  And you say that he is exploiting people by having a default donation of half of one percent that can be changed by anyone that bothers to read the documentation provided?

Let me say it again.  Fuck you.  By creating and developing this incredible software, he is helping not just you, and not just all p2pool users, but the entire bitcoin community.  You should do the decent thing and apologize for you ridiculous accusation.
2204  Bitcoin / Pools / Re: [320GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: March 19, 2012, 04:37:37 PM
Seriously?  People have a problem with half of a percent that can be changed to anything else, including zero, with absolutely no effort?

Screw 'em.  Leave the default where it is.
2205  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 19, 2012, 03:18:11 PM
To me, all of the evidence so far suggests that he is mining with custom software, and the control node is pushing the absolute bare minimum data out, just the hash of the block to be built upon.

If the mining nodes (bots?) were running full bitcoin clients, there would be no reason not to include transactions.  If the nodes were running normal mining clients, there would be no reason not to include transactions.

By pushing out just the previous block's hash, the one thing needed to keep the clients current, the operator probably hoped to minimize traffic and reduce the chances of detection.

Has anyone portscanned the relay node?  If the relay node is the same as the control node, which isn't a sure thing, it should be listening on a totally innocent port, like 53 or 80 or 110, but handing out the hash of the current highest block.
2206  Bitcoin / Development & Technical Discussion / Re: PetaFLOPS and how it relates to Bitcoin on: March 18, 2012, 04:19:50 AM
Why in the world are so many people so insistent on this meaningless comparison?  Floating point and integer operations aren't even done on the same hardware, which is easy to overlook since both units have been routinely packaged inside the same die for the last couple of decades.
2207  Bitcoin / Development & Technical Discussion / Re: Backups in a Multi-sig world on: March 18, 2012, 03:35:19 AM
No, you don't need to back up after every transaction.  You need to back up after every address generation, just like you need to do now.

And as I explained earlier, even with multiparty keys where no one party knows more than a single key used to generate the script/address, you can still do it if at least one party stores an identifier along with their key and all of the parties are able to identify which of their keys was used based on that identifier.
2208  Bitcoin / Development & Technical Discussion / Re: PetaFLOPS and how it relates to Bitcoin on: March 16, 2012, 07:13:15 PM
Comparisons between integer and floating point operations are meaningless.  Not just inaccurate, or merely approximate, but not even in the same universe.

Just the Xeon CPUs in that Dutch thing are capable of finding a block every 30 hours or so, or about 40 BTC per day.  Presumably, that is more than 12 euros.
2209  Bitcoin / Development & Technical Discussion / Re: Withdrawing BIP 17, and proposing BIP 18; please review patch on: March 16, 2012, 04:21:11 PM
No, it doesn't help any.

If you want to try to find a hash collision so that you can steal coins, you are better off making the simplest possible transaction, which is just one single key.  Once you've done that, it is just a matter of finding keys to match all 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible hashes.
2210  Bitcoin / Development & Technical Discussion / Re: [Paid] [Bounty: 10 BTC] Bitcoind build instructions for Centos x86 and x64 on: March 16, 2012, 06:20:47 AM
Are you guys still having problems?
2211  Bitcoin / Bitcoin Discussion / Re: Why isn't proof of stake more widely supported? on: March 16, 2012, 06:09:10 AM
Anyway, I've made these kind of arguments many times over the past two years, quite literally on both sides of this issue.  What it all comes down to is that PoS doesn't offer an advantage over PoW, but attempts to solve a presumed future problem that I (no longer) agree exists.  I also do see potential problems in it's practical implementations, although those may not be insurmountable.  However, the very biggest problem with PoS is that a major entity could literally come in and buy it out and become a new central bank, as the requirement for having more than the processing power of the whole of the honest network no longer applies to a PoS miner with a large enough of a stake.  Your not going to solve a problem here.

Just in case anyone missed it.
2212  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 15, 2012, 01:09:12 PM
Note that any mechanism forcing people to pay a fee will most certainly lead to fewer transactions. Users would try to bundle more payments in fewer transactions. Obviously this also lead to less blockchain bloat, but as a general rule I think it's safe to say we want more transactions.

The voluntary fee scheme is something I saw as a potential source of problems since I first read about it. As you say, miners can't make the network pay a fees but they have the right to exclude transactions. This can lead to an uncertainty over what fee will make my transaction go through that ultimately hurts the whole system. I believe we will have to abandon this charity shop style of operation and switch to a "serious business" style of operation, where people know expected prices and are given some guarantees of getting what they paid for, in regards to fees and transactions.

The problem is that right now the subsidy is still huge.  D&T thinks that there should be a minimum fee of 0.01 BTC per transaction.  This is still one or two orders of magnitude too low for transaction fees to be meaningful today.
2213  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 15, 2012, 01:02:03 PM
We (meaning the community) are paying for a service.  This person has found a loophole in our agreement, and they are taking the pay, but not providing the services that we desire.  The work may be worthless to them, but it is not worthless to us.  And since we are the ones paying, we have the right to revise the terms under which we'll pay for the work.
May be 50 BTC is the reward for securing the blockchain, not for including TXes ?

Seriously?

If that is the case, then the whole system was set up totally wrong.  The reward for securing the block chain will get lower and lower over time, presumably as the need for security grows, and will eventually end up at zero.

No, the two are combined for a reason.  There is no block chain to secure without transactions, and there are no transactions without the block chain.  You literally cannot have one without the other, and so the reward is for doing both jobs, not just one or the other.
2214  Bitcoin / Mining / Re: My theory of shares by volume vs. speed on: March 15, 2012, 05:02:45 AM
Bitcoin mining is like playing the lottery and every !!hash!! is a ticket.
Let's say i buy 10 lottery tickets and in the household next to me live 10 people and everyone of them buys one ticket. The household of my neighbor now has obviously the same chance to win. That's pretty much your example with the 1GH/s card and the 10 100MH/s cards.
Others have already said whats wrong with your math.

But there actually is this kind of effect with distributed hashing power:

Let's say i have 2000 CPUs and each of them needs 2hours for one hash.
You have 1CPU that needs 0.002h=7.2s for each hash.

That means that we have the same hashing power but I will never find a hash and therefore no block because i have to start all over again after ~10min when a new block comes out.

But that problem doesn't exist, because noone is hashing with such a CPU :/
And it's not related to your calculations which are just wrong.

Actually, your calculations are just wrong too.  There is no progress.  You are no more likely to find a block after 10 minutes than you were after 10 seconds, or 1.  In the long run, you will have nearly identical performance.
2215  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 15, 2012, 04:54:27 AM
"free" = "almost free".  0.001 BTC extra per block is essentially free.  In aggregate transaction fees are worthless.  Economic theory would suggest when something is worthless people don't care about aquiring it.  It isn't an "exploit" that someone doesn't go out of their way to complete worthless work.  Do you pick up pennies on the street?  Should you be forced to do so?  What if they weren't pennies and instead were penny dust where it multiple just to be worth a single penny?

0.001 BTC per block in fees is ~= worthless.  It isn't worthwhile to mine transactions, hence someone not doing it isn't an exploit.  Honestly miners only include fees to "support" Bitcoin not out of any economic value.  If in aggregate transaction fees were higher then there would be more economic incentive to include them.

You did finally convince me though so congrats.  I will be modifying the p2pool code to exclude all transactions without a fee of at least 0.01.  I won't be including worthless transactions either so I will be exploiting too.  I will make the changes available by open source so anyone else can do the same.

See, this isn't like picking up pennies on the street.  Not at all.

We (meaning the community) are paying for a service.  This person has found a loophole in our agreement, and they are taking the pay, but not providing the services that we desire.  The work may be worthless to them, but it is not worthless to us.  And since we are the ones paying, we have the right to revise the terms under which we'll pay for the work.
2216  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 15, 2012, 04:17:44 AM
However today there really is no loss to not include transactions.  Calling that an exploit is pathetic.  "He won't include my free transactions. .... WAAHHH.  EXPLOIT.  We need to include complex and dangerous counter protocol rules to force him."

This nonsense again?

Listen up dude, the only person in this thread that is talking about free transactions is you.  The problem is that these blocks include no transactions at all.

What is under discussion now is what to do in the next decade or two, while the coin generation subsidy is still large enough that it makes sense to mine blocks without transactions.  In the long run, the market will set the fees.  You don't need to keep repeating that because we all know it.  The whole system is designed around it.  But what happens in the short run can prevent the long run from happening.

P.S.  My proposal is neither complex nor dangerous.
2217  Bitcoin / Development & Technical Discussion / Re: Backups in a Multi-sig world on: March 15, 2012, 12:53:44 AM
Sure, but you'll lose any donated money that hasn't received enough confirmations to claim yet.

I'm pretty sure that you can spend a transaction that hasn't been confirmed, but only if both transactions end up in the same block.

Also, in cases where not all keys are known to any one party, there will need to be a protocol of some sort to generate P2SH addresses.  Since it doesn't exist yet, I'm sure we can lobby for some sort of replay feature to be included.  See my previous posts in this thread for details on how that could work.
2218  Bitcoin / Development & Technical Discussion / Re: Backups in a Multi-sig world on: March 14, 2012, 11:25:26 PM
Not sufficient. What if I send money to you with a return address in case you don't claim it (your-key OR my-key)? The backup won't have my public key, so there's no way to recreate the P2SH hash.

(Mine OR Yours) is not the sort of transaction anyone would use to store their money.  The only safe thing to do when getting paid by a transaction like that is to immediately send the money to a different address, hopefully of the form ((Mine AND My Agent's) OR Mine).
2219  Bitcoin / Bitcoin Discussion / Re: Bitcoin & Tragedy of the Commons on: March 14, 2012, 10:32:41 PM
There is an aspect of this which is textbook tragedy of the commons, but it's kind of abstract. The scarce public good being consumed is the bargaining power of miners. As long as miners have that power, they can demand enough fees to fund the mining required to secure the network. If a miner accepts low-fee transactions, he consumes this bargaining power (since then senders will have no reason to include fees) for his own benefit, making everyone worse off (miners who are now unable to collect fees, and Bitcoin users who will now not have a secure network).
I don't think you quite grasp the way markets work. What you're describing makes no sense to me. The mining network will form a near-perfect market environment where some will have a business based on volume and some will base their business on higher prices and faster transactions. Miners won't just quit in the same way as they do now, if the fee they are accepting suddenly becomes unprofitable, they can simply change their fees to find a more optimal level. A more optimal level could just as well be higher, not necessarily lower.
A miner can try to demand high fees, but if 99% of miners accept low fees, nobody will be willing to pay these high fees.

You are forgetting that (unless limitations are placed), space for transactions is an abundant resource. It does not work like a market where participants manufacture a scarce product. The only thing to lose by including a transaction is bargaining power - which is everyone's, not just the individual miners.

If the mining community is too crowded compared to Bitcoin transaction counts (and to an extent price and difficulty as well, just like now), then some will quit mining and thus difficulty goes down meaning more blocks and thus more reward for everyone else (not as block rewards, but as transaction fees).
That's exactly the problem, miners will quit and the network will be less secure.

Block space is limited, as is the computing power to validate the signatures in the transactions.  Right at the moment neither of these is really scarce, as understood by laymen, but they aren't unlimited either.
2220  Bitcoin / Development & Technical Discussion / Re: [Paid] [Bounty: 10 BTC] Bitcoind build instructions for Centos x86 and x64 on: March 14, 2012, 06:28:20 PM
First, make sure you are not trying to do this as root.  There are several places where absolute paths must be specified without tilde expansion, so the path must be under /home/.  You can set the ownership of the binary to root and install it in a system path after it is built, but the build process only works as a different user.

Second, if you've recently installed zlib and/or zlib-devel, make sure you run ldconfig as root to update the library cache and symlinks.
Pages: « 1 ... 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 [111] 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 ... 195 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!