Bitcoin Forum
April 19, 2014, 04:20:47 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: 1 ... 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 [59] 60 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
1161  Other / Beginners & Help / Re: BitCoin miner for Android? on: February 23, 2012, 09:43:47 PM
While it might not be worth doing it on the CPU of the phone I would be really curious of benchmarks on a typical Android GPU.
They are powerful for being integrated in a phone[/b], and their power usage is low probably.

Added some emphasis for you.

Maybe look at litecoin, but I think you are wasting your time.
1162  Other / Beginners & Help / Re: Darn it on: February 23, 2012, 09:41:09 PM
Thanks!  That's real bad news!

I think I'll have to stick to using Mt. Gox or an equivalent - I can't trust Bitcoin Walle - It's happened twice!


Why are you doing to your poor computer? I haven't lost any wallets...
1163  Other / Beginners & Help / Re: How to setup a server to solo mine BTC/LTC on my lan? on: February 23, 2012, 07:08:27 PM
Check out p2pool.  It's really easy to get running and will be lower variance than solo mining.
1164  Bitcoin / Bitcoin Discussion / Re: How to Turn Bitcoin Into the Top Payment Network and the Currency of the Future on: February 22, 2012, 07:36:10 PM
I just can't picture carrying a stack of what are essentially gift cards with varying amounts in my wallet.  I hate going into Jamba Juice and handing them a card with 5 cents on it and then digging around to find another card with 12 cents on it.

A cheap camera phone could sign a transaction and then give it to the merchant to relay.  No need for the customer to have internet access or an expensive smart phone.  We have a system that doesn't require trusting merchants.  Lets keep it that way.

I also think having one device (yes, even one with batteries) is better than a bunch of plastic or paper.  I see physical coins as a system for trading when there isn't electricity/internet around and as something to help people who are used to paper cash and coins transition away towards a digital currency.
1165  Other / CPU/GPU Bitcoin mining hardware / Re: Does running extension cords to your rigs screw up the power? on: February 22, 2012, 05:12:20 AM
Running extensions cords for anything permanent is against fire code for a reason.
1166  Other / Off-topic / Re: Butterfly Labs - Bitforce Single and Rig Box on: February 22, 2012, 05:04:35 AM
I want this to be real
1167  Bitcoin / Pools / Re: [270GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: February 22, 2012, 04:48:20 AM
The limitation of Bitcoin is that the block chain is only aware of the total hashing power, not individual miners, and thus can only adjust accordingly. P2Pool protocol chain is sort, and is easy to change, and each instance of P2Pool is aware of both the pool hashing power and each instance's local hashing power.
Would it be possible to just change the algorithm from adjusting difficulty to make a pool block every ten seconds based on overall pool hashing power, to one that bases it on the fraction of your hashing power compared to the overall pool? Have the difficulty start out at average, and as you mine, every thirty minutes recalculate your local difficulty based on reported hashing power, so that strong miners get increased difficulty and fewer shares and weak miners get more?
Or is this too difficult due to all blocks in the chain needing to be the same, or risky due to being easily hacked?

Currently shares are all the same because (your payout) = (your shares) / (total last n shares).

While you could make shares variable in difficulty and make it (your payout) = (sum of your shares difficulty) / (total sum of last n shares difficulty) it doesn't get around the ophan problem.

Bitcoin rarely has orphaned blocks because the round time is ~600 seconds.  The shorter the round time the more likely two entities on the network find solution at roughly the same time and one of them gets orphaned.   P2pool compromises between share difficulty & orphan rate by using a 10 second round time.  It sets difficulty so someone will find a share roughly 10 seconds (and hopefully most of the time that "solution") can be shared to everyone else to avoid duplicated work in time.

So to avoid higher orphan rate you still need the average share time to be ~10 seconds.  You could within reason allow smaller miners to use lower difficulty and larger miners to have higher difficulty but the average must still work out to ~1 share per 10 seconds.

So that solution has two problems:
a) the amount share difficulty can be vary is not much and if most miners are small it is very little at all.
b) larger miners would be accepting higher variance in order to give smaller miners lower variance.  Something for nothing.  Unlikely they will do that.


The way I see it there are four decentralized solutions:  multiple p2pools, merged share chain, dynamic p2pools, sub-p2pools.

multiple p2pools.
The simplest solution is to simply start a second p2pool.  There is no reason only one has to exist.  Take the source code and modify it so the "alternate p2pool can be identified" and start one node.  Node can join using modified client.  Eventually client could be modified to have user indicate which instance of the network to join or even scan all instances and give user the option.   If the two pool gets too large they also could be split.  The disadvantage is that each split requires migration and that requires people to look out for the good of the network.  For example 3 p2pools with 10GH, 20GH, and 2.87TH/s isn't exactly viable.

--------------------------------------

merged share chain
In Bitcoin there can only be "one block" which links to the prior block.  The reason why is it is used to prevent double spends.  Double spend isn't as much of a problem in p2pool.  Sure one needs to ensure that workers don't get duplicate credit but that can be solved without a static "only one" block-chain.  Modifying the protocol to allow multiple branches at one level would seem to be possible.  Since this would allow oprhans to be counted (within reason) it would be possible to reduce the share time.  For example a 1 TH/s p2pool with a 2 second share time would have no higher difficulty than a 200 GH/s p2pool with 10 second share time.  There likely are "gotchas" which need to be resolved but I believe a sharechain which allows "merging" is possible.

--------------------------------------

dynamic p2pool.
Building upon that idea of multiple p2pools the protocol could be expanded so that a new node queries a p2pool information net and gets statuses of existing p2pools.  The network assigns new nodes where they best optimize the balance of the network.   If the protocol enforces this pool assignment then there is no human gaming involved and the pools will be relatively balances.  As pools grow or shrink they can be split or combined with other pools by the protocol.   Some simulation would be needed to find the optimal balance between share variance and block variance.  The network could even intentionally allow variance in pool size and share time.  Larger pools with high difficulty and large share time to accommodate very large miners and smaller pools with lower difficulty to provide optimal solution for smaller individual miners.

--------------------------------------

sub p2pools
Imagine the p2pool forming a "backbone" and for max efficiency the share time would be longer.  Say 1 share per 60 seconds instead of 10 (difficulty goes up by factor of 6).  At 1TH/s that is ~12,000 difficulty (which is high but not as high as block difficulty of 1.3 million).  Due to 12K+ difficulty the only participants on this backbone are a) major hashing farms, b) conventional pools, and c) sub p2pools.

You notice I said conventional pools.  Conventional pools which submit valid shares to p2pool are less of a security risk to Bitcoin than opaque proprietary poools. 

For smaller miners who wish a fully decentralized solution they could form/join "sub-p2pools". These pools could be tuned for different speed miners to provide an optimal balance between block difficulty and share difficulty.  They would maintain a sub-p2pool level share chain and use that to set the reward breakout for the subpool.  When the one node in the subpool solves a "master p2pool" difficulty share (12K in above example) it submits it to the main pool (which updates the ultimate reward split to include the subpool current split for that share).  subpools could be created manually (Rassah small miner subpool), or eventually dynamically by an protocol similar to the second solution.  This requires a modest change to the existing p2pool (which would form the backbone). Currently 1 share can only be assigned to 1 address.  To make sub-p2pools possible it would need to be possible to include an address list and distribution % for 1 share. 

--------------------------------------


Note: these ideas aren't fleshed out.  Likely someone can point out issues and areas where the explanation is incomplete.  They are more designed as a thought exercise to look a potential avenues for expanding p2pool to handle potentially someday 51% of network hashing power (at which point an internal 51% attack becomes impossible).   Obviously these are complex ideas which will take time to implement.  I believe that "front ends" are preferable to small miners going back to deepbit and could act as a bridge to transition p2pool from 250GH/s to 1TH/s+ while more decentralized solutions are developed.
forrestv, are you considering acting on any of these ideas?  What are you current thoughts on this?
This code is probably worthy of a bounty
1168  Bitcoin / Bitcoin Discussion / Re: How to Turn Bitcoin Into the Top Payment Network and the Currency of the Future on: February 21, 2012, 10:09:29 PM
bitcoin cannot exist as a currency and a commodity, and be widely accepted as either.

look at this scenario: sitting around at a restaurant, waiting for the price to go up so you can settle the receipt.
When/if bitcoin gets to that level of acceptance, the price won't be as volatile as it is currently and so it won't be a problem.
1169  Bitcoin / Bitcoin Discussion / Re: How to Turn Bitcoin Into the Top Payment Network and the Currency of the Future on: February 21, 2012, 09:48:40 PM
So you don't use credit cards?

Do you really think a business will stay in business if it keeps misusing people's financial information?

The worry is unwarranted and, again, the cards are disposable.
Actually I don't have a credit card.

I do use a debit card though and it has the same flaw according to you.  What you forget is that credit card companies can restore any funds stolen from me.  A stolen bitcoin private key does not have the same problems as a stolen credit card number.

I should have realized you were Atlas. Thanks for saving me time, Matt.
1170  Bitcoin / Pools / Re: Double geometric method: Hopping-proof, low-variance reward system on: February 21, 2012, 09:37:17 PM
This looks cool.
1171  Bitcoin / Pools / Re: [270GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: February 21, 2012, 09:36:17 PM
I have multiple miners mining at one p2pool server. Each miner has it's own bitcoin address. 

How is the payout split to each bitcoin address? 

Does each miner need to find blocks added to the share chain or is the payout split to the addresses based on work submitted to my p2pool server? 

Thanks
The workers are paid for the work they do.  Pretty simple.

Any particular reason you are mining to different addresses?  I have 2 p2pool servers (one primary, one backup) and they both mine to the same address.  My miners just have a descriptive username instead of a payment address.
1172  Bitcoin / Bitcoin Discussion / Re: Armory Crowdfunding: Get rewards for contributing! on: February 21, 2012, 09:28:12 PM
Oh yeah. The original reason I came to this thread.

I tried to donate with a credit card, but the payment page never loaded Sad

I'll donate with bitcoin soon Smiley
1173  Bitcoin / Bitcoin Discussion / Re: Armory Crowdfunding: Get rewards for contributing! on: February 21, 2012, 09:26:59 PM
Port Armory to Javascript and I'll donate $100 in Bitcoins.
I don't think "port" is what you want.

However, there will eventually be support for a JSON-RPC.  You should be able to build whatever you want with javascript once that exists.

I don't think you'd want to move something that uses up 4GB of RAM to Javascript-- ever.
The client should only have to download the most recent blocks in the chain. This whole issue disappears once that happens.
What benefit do you see in having the blockchain in javascript?

Build a web app that uses javascript to interact with the armory server's JSON-RPC.  "Easy" web wallet with everything that Armory has.  I say "easy" because it's a lot of work to build a good web wallet even if the logic is mostly in armory.  It also definitely isn't easy for the armory dev.
1174  Bitcoin / Bitcoin Discussion / Re: How to Turn Bitcoin Into the Top Payment Network and the Currency of the Future on: February 21, 2012, 09:23:11 PM
What I mean is that people won't have to put more than say $20 on a card.
This is not convenient.  What happens when I want to spend $25? I go to my computer and transfer funds around and then have to wait for 6 confirmations?

Giving anyone your private key, even a "trusted" merchant, is incredibly foolish.  After swiping your card once, you could never trust it again.

A smart phone app that reads a QR code is the easiest and most secure so far IMO.

https://bitcointalk.org/index.php?topic=58552.0 links to this video that shows how easy it can be http://www.youtube.com/watch?v=pDOcLros-w0
1175  Bitcoin / Bitcoin Discussion / Re: Armory Crowdfunding: Get rewards for contributing! on: February 21, 2012, 09:11:25 PM
Port Armory to Javascript and I'll donate $100 in Bitcoins.
I don't think "port" is what you want.

However, there will eventually be support for a JSON-RPC.  You should be able to build whatever you want with javascript once that exists.
1176  Other / CPU/GPU Bitcoin mining hardware / Re: Mining rig extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] on: February 21, 2012, 07:59:09 PM
watching this
1177  Bitcoin / Pools / Re: [270GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: February 20, 2012, 07:41:15 PM
I have read the wiki but still do not understand how I get namecoins as well as bitcoins with this pool. What do I do to get namecoins?
Setup namecoind with "server=1" in the conf and add "--merged <namecoin info>" to your run_p2pool.py command.  What more do you need to know?
1178  Bitcoin / Pools / Re: [270GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: February 20, 2012, 06:43:24 PM
Solved 2 namecoin blocks! Woo.  Been mining since last June and this is the first solves I've gotten lol.
1179  Bitcoin / Pools / Re: P2Pool Ubuntu Linux Installation Service - For Mining Farms on: February 18, 2012, 10:04:36 PM
Well then you should definitely get a p2pool livecd working since it shouldn't be a problem for you Smiley
1180  Bitcoin / Pools / Re: [270GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: February 18, 2012, 06:22:36 PM
I've been following p2pool for a while and it really looks like we need a FAQ

We already have a wiki page, so lets put it there once we have some questions figured out.  In no particular order...

1) What is PPLNS?

2) Why am I not getting any shares with my NVIDIA after waiting a whole 5 minutes?!

3) Why am I getting so many rejects?

4) What stops the pool operator or the block finder from stealing a block?

5) Why does it say "Generated?" I want to spend my coins now!

6) Do I get paid transaction fees?

7) What are these payments I'm getting that aren't generated?

Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners?

9) Do I really need the WHOLE blockchain?

10) How do merged mining payments work?


I'm sure theres some more.  I just see these asked a lot.
Pages: 1 ... 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 [59] 60 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
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!