Bitcoin Forum
July 04, 2024, 03:24:14 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 [231] 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 »
4601  Bitcoin / Development & Technical Discussion / Re: OP_NOP-appended transactions - how long do non-standard transactions wait? on: June 03, 2011, 07:58:25 PM
Those are intentionally crafted by my eligius_sendonly branch. The non-standard output is in fact the transaction fee, but encoded such that only Eligius can benefit from it. This was at the request of some miners who apparently see it as a way of contributing to the pool. They should be confirmed every 4 hours on average, given Eligius's current pool size.
4602  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" (~130 GH/s) on: June 03, 2011, 04:08:48 PM
Mainly because this forum software makes no effort to notify me that I have messages. Apparently there's 9 since the last time I manually went to check...
4603  Bitcoin / Development & Technical Discussion / Re: Fuzzycoin: defending against the kiddie-porn-in-blockchain attack on: May 31, 2011, 04:32:15 PM
1. Transfers to young addresses incur high transaction fees. Transaction fees drop as addresses age in block chain.
Addresses aren't stored in the block chain, except as outputs to transactions. Since every transaction generally has a unique address for its output (except for donations), all addresses are usually "young". When it becomes possible for merchants to use a single address for all transactions (ie, when clients can easily send an address-signed email with a transaction id), this might become viable.
2. Users cannot make exact transactions.  Say, for example, that I sign a transaction for 1.0000000 BTC.  This will only be included in a block if the miner also signs it. However, by default, miners always reject my first proposal and send back a signed proposal salted with a random number, say 0.97429313 BTC. I can then choose to sign this, and commit it to the block chain, or make another first proposal.  The whole thing can of course be automated in the original client.
Miners can't "send back" anything at all...
4604  Bitcoin / Development & Technical Discussion / Re: Txn fee back to 0.01 in rc5? on: May 31, 2011, 04:28:06 PM
BTW, Luke-Jr pool accepts transactions with lower fees...
I can't seem to figure it out though, I added "-addnode=173.242.112.53" when launching Bitcoin but it still forces the 0.01 fee. Must be too late at night for me.... Huh
git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git eligius_sendfee && git merge FETCH_HEAD
qurashee also built my branches (use at your own risk!): http://eligius.st/~qurashee/
4605  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 31, 2011, 04:26:03 PM
bitclockers pool has 3 seperate servers, 2 in the US and 1 in the czech republic maybe have a word with them as its a great feature which makes it fully redundant too Smiley
But they don't payout immediately as part of the same block you worked on Wink
however that means something is off with my calculations: the bitcoin mining calculator shows .56 btc per 24 hours of 240mh/s, whereas on the pool it's only .36, which is a big enough difference to question rentability...
The estimate isn't per 24 hours, it's per-block; right now, Europe should find a block on average every 21 hours, which works out to 0.41 BTC every 24. You should see your estimate creep up (possibly slowly) toward the point where it reaches the full .56 BTC per 24 hours (which would be .49 BTC per 21).
4606  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 31, 2011, 11:52:58 AM
The EU pool on Eligius has been having bad luck recently.  Only two blocks solved in the past week!  Average should be about 3-4.
It's a pretty small pool, so you are going to have runs of good or bad luck like this.  When the luck is better you will make a lot, when the luck is bad, not so much.
Luke: since Eligius is still a little pool, why not join the eu and us pools together to minimize the variance?
I'm not sure why everyone assumes this is easy, or even possible... The main difficulty is finding a way to handle network issues when they can't talk.
4607  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 30, 2011, 06:34:48 PM
I've been using this pool for a while.  I use ufasoft on my i7-920 and poclbm with my GTS250.  I've noticed that my cpu mining gets invalid results once maybe 20.  My gpu gets invalids once or twice out of 10.  My gpu mines at 28m whereas my cpu mines at 6.  Why does my gpu get invalids so often?  Is it just because of the different miners?
What address?
4608  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 30, 2011, 04:42:14 PM
FYI, if you would like to take advantage of Eligius's lower transaction fees, you can clone/merge my eligius_sendfee branch:
Code:
git clone -b eligius_sendfee git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git # If you don't have any code yet
git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git eligius_sendfee && git merge FETCH_HEAD # Inside an existing git repository
I was also asked to write a branch that sends transactions only accepted by Eligius. Replace "sendfee" with "sendonly" to get that. It works by paying fees directly to a "magic" Eligius address rather than normal fees, and making that output non-standard to discourage other miners from including it.
4609  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 30, 2011, 02:41:58 PM
I know this is an error clearly on my side but would it be possible to throw an error when a login is attempted with empty username so that others do not get into the same situation?
There are many possible errors. Yours is the first I've seen with a null username. Checking for errors adds overhead to every single getwork, and either changes the C code or requires a very carefully crafted MySQL query (which I am aiming to remove for efficiency anyway). I also have other things to work on before I declare Eligius to have formally left the "experimental" stage. So I have to say, if address checking for mining is to be implemented, it won't be very soon... sorry.
4610  Bitcoin / Development & Technical Discussion / Re: Txn fee back to 0.01 in rc5? on: May 30, 2011, 05:24:58 AM
BTW, Luke-Jr pool accepts transactions with lower fees...
I can't seem to figure it out though, I added "-addnode=173.242.112.53" when launching Bitcoin but it still forces the 0.01 fee. Must be too late at night for me.... Huh
git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git eligius_sendfee && git merge FETCH_HEAD
4611  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 29, 2011, 09:07:23 PM
I had problems with phoenix when I first joined.
There's definitely something seriously wrong with Phoenix. Perhaps someone should ask the author to figure out what? :p
4612  Bitcoin / Development & Technical Discussion / Re: Txn fee back to 0.01 in rc5? on: May 29, 2011, 01:13:40 PM
The fact that the transaction fee is forced annoys me. I am still using 0.3.20 because of that fact.
Hasn't it always been forced? It seems the correct solution is to include a "Optional fee" in the send dialog, and if it's too small, display a confirmation ("... Do you want to send it this way anyway? Yes/No") if it's "too low". But nobody's submitted a patch for that afaik. Wink

If i want to wait for 10 hours for the 1st confirmation, why not let me ?
Don't assume it will necessarily get accepted ever...
4613  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 29, 2011, 01:06:17 PM
Someone asked 1BTC or once a week (once the credit is a week old? pool credits from the week? dont know), but 1.0BTC has exploded over the last 6 weeks and is about to get a lot higher.
I will, of course, gradually drop the minimum as the value comes up. The main point is to save you the transaction fees when you go to spend them.
4614  Economy / Marketplace / Re: Introducing Bitbills! on: May 28, 2011, 02:36:22 PM
We are continuing to work on an easy redemption tool (it will be a flash applet that uses the webcam to send the bitcoins to your address fee free).
Why Flash? My understanding is that phones can read QR-Codes without it. I hope you plan to make it a HTTPS-only function (with a proper cert)...
4615  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 28, 2011, 12:45:45 PM
how 'bout it, luke, wanna try this first, before you put a fee?
Like I said, I'm not putting a fee. And there's no easy way to figure out the overall pool costs. Hence, it's ok if people just donate what they consider a fair amount every once in a while. Smiley
4616  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 28, 2011, 01:26:18 AM
FYI, after a week of testing on Europe, I have calculated that a patch I wrote decreases duplicate work by 0.7%. Given the current pool size of 60 GH/s, that means we now (once I apply it to the USA pool) accomplish a whole 420 MH/s extra than an unpatched bitcoind, or almost 1 BTC per day at the current difficulty. Even half of that, 0.50 BTC per day, would take only until the end of the current difficulty to cover the expense of the time I spent writing the patch.

In my mind, this would justify adding a long-term 0.7% "fee" to the pools, but I'm not going to do that. Instead, I'm going to just publish the information and ask everyone to keep this fact in mind when considering donating to the pool.

If anyone would like to double-check my math, let me know and I'll setup an account for MySQL access. I started calculation from UNIX timestamp 1306000000 (about a week ago), but it should be safe to start as early as May 11th. During this time, Europe had the patches, but USA did not.
4617  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 27, 2011, 11:49:21 PM
Hi! I just wanted to extend a note of gratitude for the efforts of yourself and your collaborators on the Eligius pool. You've done well bootstrapping this thing and it appears to be polishing up and gaining support nicely.
Thanks. I also appreciate donations, as the pool's fee structure doesn't really cover expenses (it mainly exists to create numbers for testing). Smiley
4618  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" on: May 27, 2011, 08:07:32 PM
I have shutdown the Europe pool temporarily and redirected its DNS to USA due to discovering a major bug (which accidentally never made it to the USA pool). I could use some help debugging it in #Eligius if anyone wants to volunteer some brainpower.

Edit: False alarm. Europe is and has been working properly. Pool brought back online.
4619  Bitcoin / Bitcoin Discussion / Re: Real names on: May 27, 2011, 05:05:48 PM
FWIW:

Luke-Jr - Luke Dashjr, core developer (of Spesmilo), Eligius pool admin, and owner of Lightfoot Hosting
4620  Bitcoin / Development & Technical Discussion / Re: [PULL] Update RPC server to use asynchronous IO on: May 27, 2011, 04:26:50 PM
Further proof: luke-jr has a similar (though VERY hacky) patch he uses or bitcoind falls over for Eligius, his is a threaded implementation that would need quite a bit of cleanup though.
Sorry, but my patch probably doesn't help your case. Some corrections:
  • It's not really that hacky, I just never bothered to make it work with SSL.
  • It doesn't help failover in any way.
  • It requires each RPC command to enable threading-- currently I have only enabled it for getwork.
  • Eligius only needs/uses it for calling RPC command from inside the coinbaser (which blocks getwork).
Pages: « 1 ... 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 [231] 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!