Bitcoin Forum
October 03, 2022, 11:00:27 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Economy / Services / [Odoo/OpenERP] Web Developer (No longer available) on: January 06, 2015, 06:45:35 PM
No longer available, but my Github is still up at in case you're curious and think you might still have need of my programming services when things start cooling down for me.
2  Economy / Scam Accusations / Hashfast ToS Versions on: January 07, 2014, 02:58:19 AM
Hashfast has been changed its terms of sale without warning and without noting revisions many times. They seem to be under the impression that such changes can take effect retroactively. That is not the case, of course. However, many of us were not wise enough to save a copy of the particular ToS we agreed to when we agreed to it. This thread exists for the purpose of reconstructing the history of their ToS and for helping affected members acquire copies of the ToS they agreed to. I don't expect any legal action without this particular document to get very far.

I will be keeping an eye on this thread and updating this post with a timeline linking to the variations of the ToS and when they were first spotted. If you have any datapoints to add, please post them here. If you can confirm any of the datapoints posted here (aside from the current one, which we can all see for ourselves), that would be helpful as well. And please, keep the extraneous chatter to a minimum.

Edit: This resource already exists at Locking the thread, but keeping it up to help other people find the wiki via the forum's search bar.
3  Bitcoin / Group buys / [ANN] Avalon Gen. 2 Chips Group Buy on: September 24, 2013, 09:29:24 PM
Group buy details

Chips are 28 mBTC each, with a minimum order size of 10 chips. The amount of Bitcoin required to cover the shipping cost is based on the "Shipping" table below and the current "sell" rate on Coinbase. Calculate what you owe in bitcoin for the chips and for shipping, and send your payments to 1LZPtQvZejprmQUovDc7CGENm2cKCftyRX. Once you have sent payment, PM me or email me at with the number of chips you ordered, the transaction ID for the payment, your forum screen name, your first and last name, the mailing address you want your chips shipped to, and your email address

Send your payment from a wallet you control and can sign messages with. DO NOT SEND FROM A WEB WALLET. In the event there is a dispute over who owns a particular transaction, you will have to sign a message to prove ownership of the sending address. Also, refunds will be sent back to the address the funds were sent from, which can cause bitcoin to be completely lost if they were sent from a web wallet. If you send from a web wallet and then lose your bitcoin because your refund gets sent back to an address the web wallet doesn't associate with your account, you will have no recourse save to try to work things out with the web wallet. I will not be able to help you, and you should have read this and followed directions anyway.

Miners (tentative)
If we can get at least 20 2nd generation K16s ordered, we'll go ahead with that as well. Cost of components and assembly for each K16 at a total of 20 miners is $218 apiece. The price will go down if we can get more orders, since about half of that price will go to pay for JohnK to design the new PCB and to cover the cost of new components. If you're already a Stumptown Miners customer and you haven't requested a refund, your cost will be $110 per miner. Again, that price will go down with the number of orders we can get above 20, since the cost of redesigning the PCB for the new chips is fixed. Please use the Coinbase "sell" rate to figure what that comes out to in BTC.

Buyer Protection
JohnK still has my identity information, and will likely be willing to do another identity escrow like he did for the first Stumptown Miners batch. I've PMed him and will let you know when he gets back to me. In the meantime, you'll just have to take my word that I will refund any funds I receive if the group buy is not successful. However, if the group buy is successful, the chips will be ordered and refunds will no longer be an option.

Terms of Sale
  • Full payment of all costs incurred is required prior to shipment to final destination.
  • Address signing is required for dispute settlement.
  • All sample chips will be given to open source hardware developers to facilitate production.
  • We assume no responsibility for any issues that may arise due to circumstances outside our control, including but not limited to Avalon failing to ship, shipment being seized by customs, shipment arriving late, etc.
  • All chips purchased are sold AS IS, with no warranty of any kind.
  • You may choose to change your address a maximum of two times.
  • In order to change your shipping address you must sign the change order with the purchase address.
  • Any funds sent may be refunded up until the point the group buy is successful, at which point you may no longer request a refund. If the group buy is not successful, the full BTC amount you sent will be refunded to your sending address.

(Apologies to steamboat, who probably finds those terms very familiar.)

How to Purchase Chips
Calculate the total BTC you owe by multiplying the number of chips you want by 0.028, and then calculate shipping cost based on the shipping provider you want (see the table below) and the current "sell" rate on Coinbase. Send that amount to 1LZPtQvZejprmQUovDc7CGENm2cKCftyRX. PM me here or email me at with the number of chips you ordered, the transaction ID for the payment, your forum screen name, your first and last name, the mailing address you want your chips shipped to, and your email address.

Send your payment from a wallet you control and can sign messages with. DO NOT SEND FROM A WEB WALLET. In the event there is a dispute over who owns a particular transaction, you will have to sign a message to prove ownership of the sending address. Sending from a web wallet can also lead to the total loss of your bitcoin in the event of a refund.

Shipping costs will vary depending on your stated preferences, but by default I will be using USPS flat rate Priority Mail shipping. If you are not in the US or want me to use a different shipping provider, please specify your preferred shipping provider in your initial message to me.

Shipping time:
|2-3 days|
|6-10 days|
|3-5 days|
|6-10 days|
|3-5 days|
Chip Amount:
|US Priority|
|US Express|
|Canada Priority|
|Canada Express|
|Int'l Priority|
|Int'l Express|

(Again, apologies to steamboat, who probably finds this table astoundingly familiar.)
4  Economy / Currency exchange / Buying and selling BTC for USD via snail mail on: September 19, 2013, 06:15:30 PM
Prices update automatically. I'm not always selling and I'm not always buying.

Place your orders here:

Machine-consumable interface can be found here:

I recommend sending the cash via certified mail if you're sending more than you're comfortable with potentially losing in the bowels of the US postal service.
5  Economy / Computer hardware / [WTS] PICs for Klondike miners on: July 08, 2013, 11:09:07 PM
In anticipation of there being shortages, I bought a mix of 256 PIC16LF1459-I/SS and PIC16LF1459-E/SS to put into miners. At present, I have only had 99 K16s ordered from my assembly service. I'm now looking to offload the remainder of my PICs.

At present, I have 157 of the PICs available, with 90 in hand and ready for immediate shipping. I'm looking to sell them for $2 apiece, to be transferred via Bitcoin. JohnK has my personal information and is doing identity escrow for my assembly service. I'm willing to extend that escrow protection out to this, since it's an extension of what I'm doing with Stumptown Miners.

Let me know if you're interested, or if you have any questions.
6  Bitcoin / Hardware / [CLOSED] - Stumptown Miners - Avalon PCB Assembly - West Coast USA on: May 12, 2013, 10:14:27 PM
Ordering has ended. PCBs and components have been bought and received.

I am currently offering refunds of $45 per miner, for those who want out.

Current projected throughput is 100 K16 miners completed per day once the test board issues have been figured out.


Terms of Sale (formerly at

  • You will supply your own chips.
  • You will tell your group buy organizer to send your pledged chips to Stumptown Miners.
  • The price of the miners you have bought may drop due to more people from your group buy joining. Any price difference in USD between what you paid and the new price will be sent back to you as BTC.
  • There is a batch size minimum of 60 from each group buy for each design. If you order a design and there are not enough orders of that design from your group buy, you may either receive a refund or (if you are part of an early group buy) opt to have your chips lumped in with a batch from a later-arriving group. You must make the election to either have your chips lumped in with a later order or receive a refund at the time of purchase.
  • All received BTC will be converted to USD to hedge against market crashes. (This step is necessary as the assembly and fabrication plants do not yet take BTC.)
  • Refunds will be calculated according to the USD value of your BTC at the time of currency conversion. An equivalent amount of BTC, calculated at the exchange value on CampBX, will be returned to you in the event of a refund. (E.g., if BTC doubles in value against USD after you have paid, and you then receive a full refund, you will only get half the BTC you originally paid.)
  • Refunds on any of the miners (K1, K16, and K64) in your order may be requested until orders for that particular model of miner from your group buy (or from a later group buy, if you've opted to have your order bumped rather than refunded) reach 128. I will begin ordering parts for your group buy's orders at that point and will no longer be able to fully reimburse you.
  • You will be contacted via email for your shipping information once production begins. I will also arrange at least one group meeting per group buy for those of you who live nearby and want to pick up your miners in person.
7  Bitcoin / Hardware / [Avalon ASIC] US-based burnin alternative on: April 25, 2013, 11:19:14 PM
Hi all,

I'm going to be getting 480 chips as part of ragingazn/JohnK's group buy, assuming it gets funded in time. Since I'm already planning on having the PCBs for mounting the chips printed and assembled in my home state, Oregon, I was wondering if anyone else would be interested in a US-based assembly option.

I have no background in EE myself and am planning on simply passing the PCB design bkkcoins is working on to a plant nearby. Bkkcoins' design will accommodate 16 chips per board. (More info here:

To take advantage of this offer, you must be part of raginazn's group buy ( I don't want to have to deal with chips trickling in from other sources and potentially holding everyone up. Have raginazn ship your chips directly to me and I'll ship them on to you after assembly. Or you can come by and pick up the assembled unit directly, if you're willing to make the trek out to Portland.

I don't know how much this will cost, all told, but I will only be marking up the parts, printing, and assembly cost by 5% at the most.

Also, if there are enough parties interested in the single-chip USB miner the DIY group is designing, then I'd be happy to have that printed, assembled, and shipped as well.

8  Bitcoin / Project Development / Developing a secure Bitcoin service - input and ideas? on: April 21, 2013, 02:50:25 AM
Hey, I'm helping a coding bounty website get set up with Bitcoin, with an eye toward Bitcoin Bounties possibly getting absorbed into it. I'm trying to come up with some secure ways to handle receiving payment and paying out rewards and would like some feedback on what I've come up with so far. I figure this thread could also help anyone in the future who might need to handle coins in a similar manner.

Anybody have any thoughts on the methods proposed below? Any security holes come to mind?


Bitcoin cold wallet + hot wallet, no coins on server
Basically we run a copy of a Bitcoin client on an isolated machine and periodically generate batches of public addresses which we can transfer via thumb drive to a MongoDB collection on the web server. The web server then just pulls public addresses from the collection as it has need. We'd have to make sure there's always a buffer zone of unused addresses so the server never runs out of addresses. Then, once it's time to release the funds, we export the bounties to be paid to a thumb drive, import them into a local MongoDB database, run a script to create the relevant transactions, then (after auditing the DB and the transactions to make sure everything lines up) copy the transactions to a web-connected machine for execution.

If we wanted to further strengthen our security model, we could also keep the transaction-signing machine separate from the address-generating machine by having one private key per Bitcoin address and then exporting the relevant keys to the transaction-signing machine via thumb drive when it comes time to pay out.

Either way, this minimizes the risk of theft since the machine containing the primary wallet file is never connected directly to the Internet. If we keep the thumb drive and the machines involved locked down and clean, it should be nearly impossible. The weakest point is the fact that *someone* has to be responsible for physically transferring the funds, and that person could be a point of failure. (I.e., they could very well siphon funds into their own wallet, or do something stupid to compromise the machines.) If we gave responsibility for each step of the process to a different person, with each person auditing the steps taken by the person before, that would further limit the possibility for theft.

On the web server there would also have to be a copy of bitcoind running to allow us to query the blockchain and update donation amounts periodically. We would have cron run a script every five to ten minutes that would iterate over every active, in-use bitcoin address and ask bitcoind what the balance is. It would then update the reward amount in the corresponding bounty.

This is the most secure and the simplest of the setups I've so far come up with. No coins, aside from those about to immediately be sent out, are ever on a machine connected to a network, and all the technology involved is mature and production-ready.

Aside from being the most labor-intensive of the possibilities, the batch processing involved means the waiting period for the release of funds would be somewhat variable. Rather than having an automatic release of the funds after exactly 72 hours, we would see some variability based on how often the payout process is done. (This is why I say "at least 24 hours" on the "About" page of Bitcoin Bounties.)

The above process, plus timed-release transactions
If, during the transaction-signing process, we created multi-signature transactions requiring an additional signature from a private key owned by us, we could feasibly automatically complete the transactions at exactly the right time by having a script that signs the transactions with the final key when the 72 hour waiting period expires. This would also allow us to run the process with longer intervals in between. The risk would be that if the transaction-execution machine got compromised, all transactions "in holding" could get released early, which could cause problems for any claims in dispute. However, since the transactions are already locked to a certain address, they could not be rerouted to the attacker's address, so there would be very little incentive for an attacker to do this unless they happened to be the potential recipient of a disputed bounty.

Doing this would complicate the process a little further, though, and take more time to implement.

Either of the above processes, but with bitcoinjs-server instead of a cron job to keep the bounties updated
This is, honestly, what I would prefer if bitcoinjs-server were mature and production-ready. It would reduce our server resource requirements as bitcoinjs-server is supposed to be much lighter-weight, and it would allow for events to be automatically and immediately triggered by changes in bitcoin address balances. But it does not currently work on Node.js versions greater than 0.08, and it does not seem to be very actively maintained. We could adopt the project, but I don't think that would be wise at the present moment. This is a road I'd like to further explore post-launch, though, as I suspect we may run into scaling problems with bitcoind.

On the periphery, there also the possibility of using a third party service like We would have to negotiate things with them, though, since I get the feeling from their API page that they don't expect to have to suddenly deal with the amount of volume we might end up sending their way.

My own feelings are that we should start with the simplest version of option #1 (a wallet and transaction signing machine + a transaction execution machine + the web server), then transition to using time-released multi-signature transactions as soon as possible, then separate out the wallet and transaction signing machines, and then consider getting bitcoinjs-server to a state where it's useful to us.

And if all of this seems too byzantine for now, we could just start with the model I'm currently using for Bitcoin Bounties, where all the funds on the web server get sent to an offline machine from time to time, and where the offline wallet gets periodically connected to the Internet in order to send payouts. It's the simplest, and it's reasonably secure, but it's far less secure than I'd like any service of decent size to have.
9  Economy / Service Announcements / [ANN] Bitcoin bounties via Github on: April 15, 2013, 08:41:33 AM
Bitcoin Bounties

Git bitcoin

Bitcoin Bounties lets you earn bitcoin by helping out open source projects.

Here's how:
  • Connect your Github account and give us a bitcoin address to send your earnings to.
  • Find an issue on the issues page and fork the associated project.
  • Make a commit to your fork that fixes the issue and issue a pull request to close it. We'll send you the issue's bounty within 24 hours after the pull request has been accepted and the issue has been closed.

To help maintain the service, Bitcoin Bounties keeps 0.5% of all bounties.

Git love (for your project)

Just copy and and paste the URLs to your most pernicious issues into the box on the login page and send some bitcoin to the addresses we automatically generate for you. And if other people want to help sweeten the pot, all the better: all funds sent to the bitcoin address generated for an issue will go toward rewarding whoever authors the pull request that closes it. Share the issue's page and see how much you can raise!

Technical details

Bitcoin Bounties is hosted on an EBS-backed m1.small EC2 instance, with the database and hot wallet kept on an additional four RAIDed EBS volumes. All bitcoins sent to the hot wallet get passed into an offline wallet and held there until at least 24 hours after the Github issue is closed. If there is a dispute over the bounty's proper recipient, you must get in contact with me within that timeframe.

If the recipient of the bounty has not registered their Github account with Bitcoin Bounties, I will get in contact with them so they can claim their bounty.


Please let me know if there are additional features you would like to see at, or if you have any questions or concerns.

10  Economy / Services / [WTB] Japanese brush illustrations of yoga poses on: April 11, 2013, 02:37:27 AM
EDIT: Found an artist! Thank you to those of you who messaged me.

I'm looking to commission some yoga illustrations for my side project, There are 186 pose cards, though a number of them are just the same pose under different names. I'm hoping to get a simplistic, minimalist feel. Something along these lines:

11  Bitcoin / Bitcoin Discussion / #BoughtWithBitcoin Twitter campaign on: June 30, 2011, 09:19:00 PM
Help raise awareness about Bitcoin's usefulness. If you've used bitcoins to buy anything, tweet what you bought and add the #BoughtWithBitcoins hashtag.!/search?q=%23BoughtWithBitcoin

Post here after you tweet to keep this thread on top!
12  Bitcoin / Mining support / Solo mining yielding less than 50 BTC per block on: June 28, 2011, 06:14:45 PM
Hey, I've been solo mining since June 12th. I copied the wallet on my mining server over to my laptop so I would be able to see when I solved a block. I managed to successfully solve a block for which I received 50 BTC. Later on I received a couple pending payments from BTC Guild. Since then I've managed to solve two more blocks, but for these I only received 0.36299659 BTC and 0.12603918, respectively.

Does anyone know what's going on? Where are my bitcoins...?  Sad
13  Other / Obsolete (selling) / 40% off at BitBrew! Today only! on: June 18, 2011, 08:31:17 PM
Get 2.5 BTC worth of coffee for 1.5 BTC.

Only two more people need to buy for this offer to be valid!
14  Bitcoin / Mining / Evolution of a 3.3 Gh/s setup: the importance of having the right software on: June 01, 2011, 04:58:10 PM
For those of you who are wondering how much difference the right combination of OS, SDK, mining software, and overclocking can make, learn from my tale as illustrated by this graph:

Section 1:
This is where I began setting up my rigs. One 2x6990 running Ubuntu 11.04, SDK 2.3, Diablo Miner. Clocked at 950/300. Probably throttling a bit due to overheating.

Section 2:
Rig #2 comes online. It's a 3x5970 running Ubuntu 11.04 64-bit, SDK 2.1, and Diablo Miner. Stock settings in the first section. With each break you can see where I took the system offline to try retooling things. The software stayed the same, but I experimented with different core overclocks and memory underclocks. At the end I was running 900/175 on the 2x6990 and 850/300 on the 3x5970. Overheating is a pretty big problem for a couple of the 5970s, even though I'm using PCIe extenders. The 6990s are cool and stable, though only giving me a combined output of 1Gh/s.

Section 3:
A gap where I take the whole system down again to install SDK 2.4 on the 6990 machine. Clocked at 900/300. I also switch to the phatk kernel on phoenix. The part of this section after the gap is my 2x6990 rig all by itself.

Section 4:
I put a fresh install of Ubuntu 11.04 64-bit and SDK 2.1 on my 3x5970 box and start using the poclbm kernel on phoenix. Clocked at 825/175. Everything's running cool, with a peak temperature of ~79 degrees celcius on my 3x5970.

Full disclosure:
Both rigs are caseless. The 6990 rig runs in the upper 60s to mid 70s range with 3 fans. The 5970 runs in the upper 60s to 70s range with 2 fans. All fans used are Scythe Ultra Kazes. I also have a table fan blowing directly on the 5970. Both rigs sit beneath an open window. It gets to be around 49F/9C at night where I live, which keeps things nice and cool. So far I've noticed a slight difference between my daytime hashing power and my nighttime hashing power due to the temperature changes.
15  Bitcoin / Bitcoin Technical Support / 6990 PSU requirements on: May 07, 2011, 12:06:12 PM
I'm trying to set up a mining rig right now, but unfortunately I overlooked a small detail: the two 6990s I got require two 8 pin PCI-e power cables each. My PSU has four 6+2 and four 6 cables. The 6-pin cables come straight off the 6+2 cables (wired in series, so to speak) so that makes me think the 6+2 cables on their own provide a little more juice than a 6+2 cable is supposed to provide.

I could just use two of the 6+2/6 pin cables for each of the cards, but I'm afraid that might fry my cards. I can't really afford that, so I was wondering if anyone could offer some insight here.

My PSU is a Cooler Master Silent Pro Gold Series 1200W:

Thanks. :-)
16  Bitcoin / Bitcoin Discussion / Keeping the economy honest on: May 02, 2011, 12:31:01 PM
From what I can tell, bitcoins embody a democratic, open approach to currency and economics. I like this about bitcoins, and I imagine I'm not the only one. However, I'd like to try extending this approach to the institutions that the bitcoin economy builds itself on. These institutions are, after all, going to pop up and provide the foundation for most of the latter-day companies that enter the arena. MyBitcoin and their SCI, which quite a few vendors have come to rely on (from what I can tell), is a prime example of this. If these institutions are not likewise democratic and open, they will serve to attenuate the tone of the entire economy. Bitcoins cannot be printed, but they are really hard to tie to any given individual or organization. If a bitcoin bank were to misrepresent the number of bitcoins they were in possession of and loan out more than they had, they would effectively be printing money. If they were to use different addresses for every deposit, verifying the amount of money they actually had on hand would be nearly impossible.

I think that it would be in our best interests as a group to create practices and institutions that will keep the foundation of this economy as open and democratic as the currency itself. I've begun a service similar to MyBitcoin for this purpose, and I have a couple ideas on how to keep it open and accountable, but without a system for the communal government of a bitcoin service I'm afraid it'll end up just being me over in a corner with my service enacting policies to satisfy my own ideology like some South American dictator.

My initial thoughts are to either have a direct democracy for the direction of the website, with open proposals and direct voting, or else a representative government, where elected leaders are given the right to run the website for either a term or for as long as they service the will of the customers, whichever comes first. The end result I want is a system by which a bitcoin service can be run efficiently, with its workings visible to the public and its leadership directly accountable to the people they are serving.

Does anyone have any ideas on how that might be achieved?

Also, does anyone have any ideas on how a community might be able to keep an institution honest? As far as banks go, I was thinking it might be wise to organize annual or semi-annual bank runs, where all the customers of a bank withdraw all their holdings at the same time. This would help keep banks from playing fast and loose with other people's bitcoins and would force them to keep their dealings at least partially transparent.

What do you think of this idea? Does anyone have any more ideas like this? Or am I barking up the wrong tree entirely?
17  Bitcoin / Project Development / Bitcoin Pouch: A Community Driven Bitcoin Service (w/ JS-Remote!) on: April 27, 2011, 09:31:00 AM
Hey guys, I've finished the project I've been working on! Well, the first part anyway.

Bitcoin Pouch is meant to be an open-source, community driven financial service similar to My Bitcoin. I'm hoping to run it under a model of governance that will ensure direct accountability to the website's users and complete openness of process. I want this to be community-owned and run. I started this project because I felt like something like this could be a great boon for the Bitcoin community.

There remains a lot to be done, but for now it's ready to be tested. I've got it up and running alongside a bitcoin daemon on testnet. Could you all go kick the tires a bit and let me know if you find any bugs or vulnerabilities, or if you have any suggestions for new features? (Note that while the website remains in alpha testing, any accounts you create there may end up getting deleted at some point before the full production launch.)


Let me know what you think.


An important note I forgot: Bitcoin Pouch provides a JSON-RPC interface similar to the one the bitcoin client provides. An interactive client and method list is available once you've logged in to Bitcoin Pouch at The interface itself resides at At present it's not working with cross-domain calls. You can verify this by entering the interface's URL and your Bitcoin Pouch login information in the js-remote demo at If anyone wants to help with the project, that would be a great place to start.
18  Bitcoin / Bitcoin Technical Support / Building in CentOS 5.6 on: April 20, 2011, 09:38:23 AM
Anyone have experience building bitcoind in CentOS 5.6? I've been trying, but the list of dependencies keeps growing. Some sort of procedure/script (or even a binary, if you've got one) would be incredibly helpful!

Thanks. :-)
19  Bitcoin / Project Development / Bitcoin daemon on WebFaction on: April 17, 2011, 09:01:38 AM
Has anyone had any luck getting the Bitcoin daemon running on a WebFaction server? I'm developing a bitcoin service and need some way of getting the daemon running. Right now the binary won't run because of missing libraries. Namely I get this error:

./bin/32/bitcoind: /usr/lib/ version `GLIBCXX_3.4.9' not found (required by ./bin/32/bitcoind)
./bin/32/bitcoind: /lib/ version `GLIBC_2.7' not found (required by ./bin/32/bitcoind)

Any insights?
20  Bitcoin / Project Development / Need testnet bitcoins for testing on: April 16, 2011, 08:04:59 AM
I'm working on a bitcoin service at the moment and have gotten to the point where I need to do some testing with bitcoins. Unfortunately it looks like the testnet bitcoin faucet is down. Anyone know where I can get some testnet bitcoins...?

Thanks. :-)
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!