 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
QR code scanner. If someone wants to deposit BTC, they transfer the BTC they want to deposit into a one-use wallet, and then print out the wallet's private key into a QR code on a piece of paper.
When you get to the machine, scan the QR code, machine verifies BTC is still on the address, and then dispenses Euros.
Problem solved?
|
|
|
|
|
Seems like the simplest defense against this would be to use a moving average to base the withdraw limits off.
|
|
|
|
Because some of us stuck with bitcoins.lc when it had a 2 day block of doom when it was starting? That logic leads to the people that helped bitcoins.lc start leaving rather than sticking with it, causing the pool to never take off  |
|
|
|
About the second point : seems complicated. How about simply putting the 599 previous shares in every found share, and when one is a "winner", pay all the previous 599 shares ? Regardless whether they are from a previous block or not. This is much simpler, allows complete decentralization and still pool-hop resistant.
This means that people will get double-paid if there are two blocks in short succession and some people won't get paid at all for their shares. Another option might be to keep a list of the people who have not yet been paid for their shares, and always pay the oldest shares first. |
|
|
|
The network finds, in average, 1 block every 10 minutes (and it's often less because the difficulty only resets every 2 weeks).
A block should be found, in average, after 600 of your shares. So that's pretty much 1 share per second to announce to all the miners ! Incorrect - this assumes a *single* p2pool represents all of bitcoin's hash network, rather than only a small fraction of the total hash power. If p2pool becomes popular enough, it can be split into multiple sub-pools. Also, you claim it to be mostly decentralized at the moment, yet you handle the payouts. How do you ensure the generated shares only give the 50 BTC to you ? (Ie, a malicious miner that finds a "winning" share could keep it for himself and take the 50 BTC). That needs an explanation in my opinion.
Only the payouts that balance risk from short blocks to long blocks are managed centrally; the rest of the payouts are fully distributed. A malicious miner finding a winning share would have computed it already with the pool's payout proportions in mind; otherwise, his/her earlier shares would have been rejected by the other miners in the pool and would have no credit with them in the event that they found the block instead; therefore, malicious mining is equivalent to solo mining. |
|
|
|
Nice. Thank you for beating me to the punch, as I've been red taped. I'll go audit your code and give suggestions this weekend since I'm still unable to write code. What license is your code under? |
|
|
|
|
Stickying the largest pools causes them to only get larger, unfortunately, which is a risk to the health of bitcoin due to both the 51% problem and the attractive DoS target problem :/
|
|
|
|
|
Mailing lists will suffice for development. I think that not having any officially sanctioned forums will work just fine.
|
|
|
|
|
This already is partly modeled in the GPG web of trust. Hmm, that's an idea - I wonder if I could put a Bitcoin address as a comment on my keyring.
|
|
|
|
For some reason I'm still getting about 7% rejected shares. If everyone else has about 1% I'm sure I'm doing something wrong.
What miner are you using, and what's your approx location? |
|
|
|
As I mentioned in another thread, maybe it's time to focus bitcoin.org like a typical open source project forum and leave anything outside of the focus to other sites.
bitcoin.org can set up a wiki page where any site running a bitcoin forum can list themselves.
An excellent suggestion. I agree but think that for other sites to thrive bitcoin.org should, as suggested eventually try to limit its scope to core Bitcoin functionality and architecture issues. An excellent point as well regarding the social engineering and single point failure vulnerabilities inherent in the current format. Also agreed - it would be good to have bitcoin.org officially sanctioned discussion be solely about development efforts, and leave other community-building to a variety of different user-operated fora. |
|
|
|
What DID generate a huge amount of interest was Bitcoin as a barter medium. Clients hate to fork over a wad of $20s- it's a bit crude and ruins the experience for many. Within our community barter or "tribute" as a means for paying for service is very common. Unfortunately the goods and services that a client has to offer usually are not the ones that the business or it's contractors need. Bitcoins enable any client to earn sufficient funds to visit my facility with a modest investment of goods or his professional expertise. This has a great deal of appeal for salaried employees, who budget for a certain amount of time at the facility each month, and cannot easily increase their income under current market conditions, as well as for the large number of clients who prefer not to pay directly with cash for esthetic reasons.
In-house we have been referring to this as the "Cookie Factor". My neighbors will help me put up a shelf for a tin of cookies or a casserole, trying to pay them in cash equivalent to their time spent on the shelf or my time baking cookies would create discomfort all around. If I tell my clients Bitcoin is "cash", they already pay cash- so have no incentive to go through the hassles of acquiring Bitcoin. Bitcoin as a digital representation of their labor, or goods is another matter. I've been starting to think more of Bitcoin as Whuffie or a way of measuring barter-based transactions as well, FWIW. |
|
|
|
Best idea I've read so far today! but I've only been on 30 minutes this morning.
It would definitely make reading the mining section a lot easier than it is in its current state. Sometimes I go in looking for specific information and have to wade through a lot of seemingly junk posts to actually find it.
I'd prefer to have a subforum for pools so that the 5 largest pools aren't all stickied (worsening the large pool problem), and instead all the pools regardless of size are easily visible. |
|
|
|
I'm offering to pay you 5BTC should you release a detailed explanation of the problem, and the fix. I don't even mine in your pool (I actually hopped on IRC the first day you started to give you a couple suggestions/features that I would have needed to join). This way, you are now splitting the cost and the entire community as a whole benefits. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As one of the people who was trying to help track the bug down, I'm a little offended too with the "I'm going to withhold the fix", especially given that Pushpool is open source and cost a lot more than a day to develop.
I'm going to raise the bounty by another 2 btc for releasing the fix, but encourage you to just do the right thing instead of being mercenary and taking the money.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk30xMYACgkQaj+LAPvd0qQCtQCfQjbjz0HLky0RwIO6j1lqLw36
3fwAmwSbONdoFibFZ/jbZ/bjGE8RIf53
=m0/A
-----END PGP SIGNATURE----- |
|
|
|
It's GPL so it can be embedded into GPL software. I couldn't find source for the non-opencl portions. Would you mind providing a download link for the source corresponding to the 0.2.4 build? Thanks! |
|
|
|
|
