 Show Posts
|
|
Pages: « 1 2 [3] 4 5 »
|
|
Has there been an 'auto-payout during the next solved block' option? I'd gladly forgo instant payout if it saved the pool from paying transaction fees to get me paid and got me paid any balance over 1btc during the next block the pool solved at no cost to the pool.
|
|
|
|
Difficulty just changed, peoples' graphs are screwed up.
He's right. Bitcoin charts calculation of network has speed is related to difficulty. After every "visible" change the calculated hash rate jumps and then settles down in a day or two. It's happen every difficulty jump. People need to use search function. Thanks for this information! You're welcome. P.S. she  |
|
|
|
Doing so just hurts you, and someone else will come up with a winning share eventually. This is a generic problem with pools and I can't fix that today. Additionally, oblivious shares are tricky to get right and require centralized trust, which is something this system is intended to *avoid*.
Not if I want for example to manipulate the pool down. Imagine Tycho directing his entire pool (or even just parts of it) to a pool like this, creating insane amounts of (valid) shares but just filtering out ones that are >= current difficulty to artificially lower your income. He would even gain BTC on payouts(!), meaning he'll save money for servers while making sure your pool gets less attactive (as payout is less than in other pools). It then only depends if it would be chaper to buy the remaining BTC (or pay them out of his own pocket/fees) or not to sustain a "leeching attack" like this. (nothing against Tycho here, he just stands for $random_huge_pool_operator - and I don't suspect him in any way to do something like that!) Yes, I acknowledge this is a threat. Seeing if anyone has come up with a good solution. In the end you'd pay a pool with hashrate X but get BTC for a pool with hashrate X - Leechers. As this attack is not really statistically detectable, people would then start to accuse you of stealing/manipulating stats etc. This is actually not a problem. The distributed pool design is explicitly designed to be independently verifiable by as many people as wish to run distributors or mock-distributors and who can verify or sign off on the payout before it's sent out. Thus, they can examine all the proofs of work. |
|
|
|
|
Difficulty just changed, peoples' graphs are screwed up.
|
|
|
|
Transaction fees would also go to the pool, right? Correct. How about the "I find a solution but don't post it" attack, aka. "withholding winning shares"? As miners might have to be adapted for this pooling scheme anyways, please also implement "oblivious shares"! Doing so just hurts you, and someone else will come up with a winning share eventually. This is a generic problem with pools and I can't fix that today. Additionally, oblivious shares are tricky to get right and require centralized trust, which is something this system is intended to *avoid*. Can the pool require it's miners to always include some special transactions (for free), like payouts?
Yes. There could be published policies about only accepting proposed shares/solutions that contain specific transactions; participants in the DHT could refuse to grant credit for shares without those transactions, and the distributor's double-check could verify this. |
|
|
|
Google...... Perhaps deepbit with 75% controll would be better. Would have to see details but by default I do not trust them.
If I'm allowed to develop, source will be open, you'll be welcome to inspect it for yourself, I'll accept patches. Lastly, I don't plan to be the only distributor. Anyone can start a distributor simply by publicizing a bitcoin address for their distributor and convincing people to start using their new distributor address; they'd obviously be responsible for actually running the distributor after each found block to disburse funds. It just would require having enough trust such that people would be willing to point their miners at your distributor. When I get this off the ground as the first distributor, I plan to escrow 50 btc with a well known community member as a show of good faith should I fail to pay out. |
|
|
|
Any progress on this? Seems to be one of the most important outstanding issues.
I am waiting for permission from my employer before I proceed. Nearly have it, but bureaucracy bureaucracy. you need your employer to work on a private project? wtf? I think she works for Google, and is planning on working on this project during her 20% time. Correct. I actually was planning to do it outside work originally, but if Google is trying to get copyright on it anyways, I may as well use 20% time rather than my non-work time http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&group=02001-03000&file=2870-2872 (1) Relate at the time of conception or reduction to practice of
the invention to the employer's business, or actual or demonstrably
anticipated research or development of the employer; or |
|
|
|
One option is to bake pooling into bitcoin. A miner can either do conventional mining, but at much lower difficulty as he would today in a pool, or he can fulfill the role of a pool operator and aggregate blocks. This would require some clever tricks to make sure miners and operators don’t cheat each other, but the payoff is huge.
I don't believe any such "clever tricks" exist, nor do I believe they even can exist, and unless anybody has any suggestions, we might as well just stop this thread now. is one such clever trick. |
|
|
|
|
The first thing to implement would be the ability to import a transaction from a file/transmit to the network, and to export a transaction to a file rather than transmitting it to the network. My fiancee and I are planning to do this for a python bitcoin implementation we're working on; this will reduce the temptation for people to attack holders of large wallets because theit wallet could be held on and transactions could be performed offline on an airgapped machine.
|
|
|
|
So how does it help the pool at all, or "contribute to the pool" as you said?
AIUI, it's a mechanism for people to force their transaction to not immediately process in the next block to be found by any pool or miner, but to instead to wait to be processed by the eligius pool and to pay a transaction-fee-equivalent to the eligius pool's donation/voluntary tx fee address. |
|
|
|
What is the license on bitcoin-alt? |
|
|
|
Yes, diversity is good. If you do decide to go for it, do lots of testing on either the test network or with a testnet-in-a-box setup before even THINKING about handling real bitcoins. If you screw up and lose other people's money it will take a long time to earn back their trust. What are peoples' thoughts on creating a compliance test suite for Bitcoin separate from the existing C++ client, and ensuring that both the existing C++ client and new clients (e.g. bitcoinj, bitcoinp) pass the suite? |
|
|
|
Actually - "minors" are paying for porn successfully wright now, with existing methods. That problem is not solved.
You should determine what you want more clearly. Do you wand to stop minors from easy access to porn, or you just dont want have any legal related problems with this ?
That problems require different approaches and have different prices.
And, "how to not allow access to porn, for minors" (for real), is not solved anyhow, till now.
I don't want legal trouble. It looks like the 'standard' is to have a portal that requires confirmation from user stating he/she is over 18 to see previews, and then a credit card to actually purchase. |
|
|
|
I don't think so, but it probably isn't worth its price. I have one. The first fully unrolled design didn't fit (too large by factor of 3), but hopefully one of the newer designs will. |
|
|
|
Any progress on this? Seems to be one of the most important outstanding issues.
I am waiting for permission from my employer before I proceed. Nearly have it, but bureaucracy bureaucracy. |
|
|
|
|
A friend and I are about to start a Python partial implementation.
|
|
|
|
Wow, cool! I doubt I'd get anywhere close to reasonable hash rates with my nexys 2 board, but I'm glad that someone has done work to make things xilinx-compatible! |
|
|
|
|
I'd totally get behind pitching this to my friends working in porn. The porn industry (or for that matter anything with 'adult' content) has obnoxiously high credit card fees and chargeback rates. Having very low fees and no chargebacks is to its benefit.
Potential problems: trying to avoid selling such content to minors in order to comply with legal requirements could be problematic, unless one went around demanding ID from all customers. Anyone know of a non-credit-card based method of verifying customer ages?
I could probably be persuaded to produce a small amount of kinky porn sold for BTC if I can avoid selling to minors.
|
|
|
|
Total pool performance 31.25 Ghash/s from 137 workers
Ok...
Previous round (#3) duration 13 hours, 3 minutes
Perfect! According to the math it should be 14 hours on average...
Current round duration 1 day, 14 hours
CAN'T WAIT ANY LONGER!!!!! WHERE IS IT?!
Average 16 hours, 10 minutes 50% 11 hours, 12 minutes 95% 2 days, 0 hours, 26 minutes We're not outside statistical likelihood yet. |
|
|
|
However, it should still be proportional; If there are less people taking longer to solve for 50BTC, than each person should get more per block, just stretched out over a longer timeframe. So the bitcoins per 12 hours, or bitcoins per 24 hours should average out the same between pools.
Average, yes. The pool has solved 3, maybe 4 blocks. With the ghash/sec the pool is delivering, there is still substantial variance involved. Give it some time to average out. |
|
|
|
|
