Bitcoin Forum
May 25, 2024, 03:38:54 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 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 »
361  Bitcoin / Group buys / Re: [Group Buy] Avalon ASICs CHIPS! Using JohnK as Escrow! Pledge reached!! on: April 22, 2013, 10:04:39 PM
Sent payment.
http://blockchain.info/tx-index/aff93040870fd28517155318e6601402ba740a42a270b9bedad63c2837757deb
362  Alternate cryptocurrencies / Altcoin Discussion / Re: Building the next generation FAST CRYPTO CURRENCY MINING MACHINE on: April 21, 2013, 10:22:36 PM
How then does the 'average Joe' at home get involved without needing to buy specialized hardware?

Who says the "average joe" at home needs to be mining? There are tons of other ways to get involved with Bitcoin. And I don't know that an scrypt-based solution will be much better. The problem you're trying to solve is not one of "off-the-shelf" v.s. "custom," but one of "capital" v.s. "no/little capital." Even under scrypt, the wealthy will have an advantage and will eventually squeeze out the "average joe."

On top of this, you seem to be overlooking the fact that almost 100% of the mining hardware, pre-FPGA, came from AMD. That means AMD was basically the central point for the Bitcoin mining community, just as Avalon and BFL are now, except AMD never had any kind of stake in the fate of Bitcoin...
363  Bitcoin / Bitcoin Discussion / Re: What have you purchased with bitcoin? on: April 21, 2013, 07:59:35 AM
A t-shirt, some coffee beans, a brass bitcoin replica, a couple hand pies from a food cart, a couple meals at a vegetarian cafe, stocks on BTCT, an ASIC, Avalon chips, and VPN access
364  Bitcoin / Project Development / Re: Developing a secure Bitcoin service - input and ideas? on: April 21, 2013, 04:35:58 AM
That makes sense. Thanks for the feedback. :-)
365  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?

Thanks!



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.

Benefits:
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.

Drawbacks:
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 Blockchain.info. 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.

Summary
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.
366  Bitcoin / Group buys / Re: [Group Buy] Avalon ASICs CHIPS! Using JohnK as Escrow! 600+ / 780 BTC pledged! on: April 20, 2013, 06:56:38 PM
added

I don't see myself on the list...
367  Alternate cryptocurrencies / Altcoin Discussion / Re: Ripple Giveaway! on: April 20, 2013, 03:45:46 AM
rpgi6myA7y7aB5fih7mXstKvGpPoYRof1j
368  Bitcoin / Group buys / Re: [Group Buy] Avalon ASICs CHIPS! Using JohnK as Escrow! 600+ / 780 BTC pledged! on: April 20, 2013, 02:27:43 AM
I'm interested. Put me down for 480 chips (37.44 BTC).

Thanks!
369  Other / CPU/GPU Bitcoin mining hardware / Re: How about this for a rig? on: April 19, 2013, 01:23:54 AM
I second the 1200w power supply. I tried running a 3x6990 rig with a 1200w power supply and even then, after adding on the fans, it ended up being too much. Ruined the PSU. Can't speak to the CPU or RAM choice, since I know LTC uses them in a way BTC doesn't. I don't have as much experience with LTC as I do with BTC.

EDIT: Looks like the 7950 is quite a bit more power efficient than my 6990s, so you might be able to get away with a smaller PSU. Still, I'd say it's better to have a little headroom if you can afford it...
370  Bitcoin / Hardware / Re: Avalon always stop work,0Mhz.Your avalon happen? on: April 18, 2013, 07:36:29 PM
Why after 2 years you can post a topic, you couldn`t post 2 years ago?

I'm guessing they were in the newbie jail. You can't start a new topic until you reach a certain post count. Must've spent most of their time lurking, or else signed up a long time ago and only recently returned.
371  Economy / Auctions / Re: ASICMINER Auction: 10 Block Erupter Blades on: April 16, 2013, 10:52:48 PM
2@30
372  Economy / Service Announcements / Re: [ANN] Bitcoin bounties via Github on: April 15, 2013, 10:38:21 PM
Is http://bitcoinbounties.com/registration/finished supposed to be a blank page?

Nope, it's not. Thanks for the heads up. I've fixed it.

So since I'm able to login, but not tell what my BTC address is, can you add a way to view and/or change it?

registration/finished should only be showing up once you've supplied your bitcoin address. Is it showing up before then for you, then?

You can supply your bitcoin address at http://bitcoinbounties.com/registration if you have not already. You can view the bitcoin address bound to your Github account at http://bitcoinbounties.com/account. (You can access that page also by clicking your Github avatar in the nav bar after logging in.)
373  Economy / Service Announcements / Re: [ANN] Bitcoin bounties via Github on: April 15, 2013, 09:23:51 PM
Is http://bitcoinbounties.com/registration/finished supposed to be a blank page?

Nope, it's not. Thanks for the heads up. I've fixed it.

Does every issue have to be manually curated by an "oracle"?

Yes. There are too many issues on Github for me to just start pulling them at random, and I don't particularly want to start showing issues with zero donations in the issues list. I figure the friction of copying and pasting a URL into a text field is low enough as to be negligible. And if the issue is already in the system, it won't add it again, so there's not really any disincentive to adding any issues you think should be in the system without first checking for them.
374  Economy / Service Announcements / [ANN] Bitcoin bounties via Github on: April 15, 2013, 08:41:33 AM
Bitcoin Bounties
http://bitcoinbounties.com/

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.



Feedback?

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

Thanks!
375  Bitcoin / Hardware / Re: Cairnsmore2 - What would you like? on: April 14, 2013, 08:13:18 AM
Yeah, I'd be interested in a 1 Th/s miner. Would also be interested in smaller miners from you guys at lower price points as well.
376  Economy / Services / Re: hash rental idea looking for input ... please and thank you on: April 11, 2013, 08:26:01 AM
If this is going to be a project for just "friends and family," you're probably better off asking them...
377  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, yogaflo.ws. 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:

378  Bitcoin / Mining speculation / Re: Are the avalon asics legit? on: April 08, 2013, 10:56:21 PM
Looks like there's one being auctioned off on Bitmit for 15 BTC with only 3 hours to go: https://www.bitmit.net/en/item/24467-avalon-bitcoin-miner-65gh-s-asic#

The seller hasn't been verified, though, and has no ratings. Caveat emptor.
379  Bitcoin / Mining speculation / Re: Are the avalon asics legit? on: April 08, 2013, 10:10:33 PM
Aside from ASICMINER. But yeah, as far as hardware you can hold and own goes... Avalon is the most legit. They are the only ones who have shipped anything so far.
380  Other / CPU/GPU Bitcoin mining hardware / Re: What machine should I buy? on: April 03, 2013, 08:10:03 PM
I think BFL is trying to make ASICs, if only because they delivered previously on their promise of FPGA miners. However, I also think they ended up in way over their heads on this one. I think they released specific technical details before they'd actually validated those details with a prototype and are now wrestling with a much more complicated process than they'd anticipated while trying desperately to make their promised product into reality.

The last video I saw from them was of a prototype box generating nonces and pulling just over 120w, more than twice their promised 60w. They're more than 8 months late on their promised shipping date and I don't think the latest dates they've thrown out are anything other than wishful thinking on their part. I do think they've eventually ship, but I don't think they'll ship any time soon.

If you want to get into ASIC mining at this point, your best bet would be to buy shares of ASICMINER on https://btct.co/. Full disclosure: I own shares of ASICMINER.
Pages: « 1 2 3 4 5 6 7 8 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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!