Bitcoin Forum
January 17, 2021, 08:56:33 AM *
News: Latest Bitcoin Core release: 0.20.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 [3] 4 5 »
41  Bitcoin / Pools / Re: Bitcoins.lc - Finally a usuable Bitcoin Pool! (IPv6, 0% fee, Long polling, JSON) on: June 06, 2011, 09:02:03 PM
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.
42  Bitcoin / Development & Technical Discussion / Re: Is Bitcoin under attack? Where did the sudden increase in hashrate come from? on: June 06, 2011, 05:34:37 PM
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 Smiley
43  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 06, 2011, 05:14:08 PM
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.
44  Bitcoin / Development & Technical Discussion / Re: Is Bitcoin under attack? Where did the sudden increase in hashrate come from? on: June 06, 2011, 04:59:17 PM
Difficulty just changed, peoples' graphs are screwed up.
45  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 06, 2011, 04:42:26 PM
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.
46  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 06, 2011, 04:38:32 PM
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.
47  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 06, 2011, 03:23:16 PM
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 Smiley

http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&group=02001-03000&file=2870-2872
Quote
   (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
48  Bitcoin / Development & Technical Discussion / Re: [RFC] Addressing the Mining Pool Flaw on: June 06, 2011, 12:40:09 PM
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.
https://docs.google.com/document/d/1ciKH3M8WYS49ywz08beXtvpCm2wVGdzU7waKwcn_uaU/edit?hl=en_US&authkey=CJTqyOMF is one such clever trick.
49  Bitcoin / Development & Technical Discussion / Re: Client safety against theft of bitcoins on: June 05, 2011, 09:58:00 PM
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.
50  Bitcoin / Development & Technical Discussion / Re: OP_NOP-appended transactions - how long do non-standard transactions wait? on: June 04, 2011, 12:55:20 AM
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.
51  Bitcoin / Wallet software / Re: I don't like Gavin's and Jeff's Bitcoin client - can I write my own? on: June 03, 2011, 05:21:15 PM
Or you can write your own implementation of the Bitcoin protocol as we've done too:
https://github.com/phantomcircuit/bitcoin-alt
What is the license on bitcoin-alt?
52  Bitcoin / Wallet software / Re: I don't like Gavin's and Jeff's Bitcoin client - can I write my own? on: June 03, 2011, 03:24:14 PM
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?
53  Bitcoin / Project Development / Re: Bitcoin Porn anyone? on: June 03, 2011, 12:46:48 PM
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.
54  Bitcoin / Hardware / Re: Official Open Source FPGA Bitcoin Miner (Smaller Devices Now Supported!) on: June 03, 2011, 12:44:31 PM
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.
55  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 03, 2011, 12:42:27 PM
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.
56  Bitcoin / Wallet software / Re: I don't like Gavin's and Jeff's Bitcoin client - can I write my own? on: June 03, 2011, 01:36:01 AM
A friend and I are about to start a Python partial implementation.
57  Bitcoin / Hardware / Re: Official Open Source FPGA Bitcoin Miner (Smaller Devices Now Supported!) on: June 03, 2011, 01:00:10 AM
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!
58  Bitcoin / Project Development / Re: Bitcoin Porn anyone? on: June 02, 2011, 11:17:51 PM
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.
59  Bitcoin / Pools / Re: Bitcoins.lc - Finally a usuable Bitcoin Pool! (IPv6, 0% fee, Long polling, JSON) on: May 31, 2011, 04:59:44 PM
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.
60  Bitcoin / Pools / Re: Bitcoins.lc - Finally a usuable Bitcoin Pool! (IPv6, 0% fee, Long polling, JSON) on: May 31, 2011, 02:48:53 AM
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.
Pages: « 1 2 [3] 4 5 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!