Show Posts
|
Pages: [1] 2 »
|
How does one go about moving alternative cryptos to cold storage? Is there some simple tool like bitaddress.org but for all alternative currencies that would be easy to use and generate addresses with?
|
|
|
I'm trying to wrap my head around how Provably Fair works and recently ran into Bitzino's articles on deck shuffling and factoradics. What I can't understand is the need for all of the extra operations (initial shuffle, cutting the deck, factoradics, etc.) over what I think is a much simpler scheme: - Server computes server_seed and shares hash(server_seed) with the client - Client computes client_seed and shares it with the server - Server uses (server_seed + client_seed) as the seed for a PRNG - Server generates N random variables required for the result of the game (cards, numbers, slot positions, etc.) with the PRNG. For games that require unique values (card games), we keep generating until they are all unique. - Share the game results (random variables) and server_seed with the client, who can run the same deterministic PRNG with (server_seed + client_seed) to obtain the same N random variables and ensure the game is indeed fair. I simply might have misunderstood some fundamental need behind all of the extra complication. The only downside I can think of with this approach is the situation where we need unique random variables (like card games). The idea here is not to compute the full deck, since that is never needed (maximum number of cards that can occur in a game of single-deck blackjack, for example, is <25). Yes, a few collisions might happen while generating uniques, but PRNGs are very efficient and deterministic (so they don't use up the precious entropy), so that shouldn't be a problem. What have I overlooked? Update: I just realized that some of the games don't occur in a single step but rather involves sharing some of the random variables (ie. cards) between the steps. Thus, theoretically it would be possible to observe some of the deterministic outcomes, and by datamining them, in the worst case be able to deduct the rest of the results. However, given that the seed involves a true random component and is unknown by the client, and the period of the PRNGs are HUGE (2^19937 − 1 for the Mersenne Twister), I'm not sure if this would really matter.
|
|
|
Bitcoind - Apparently not very stable in server environments, requires constant restarts. Also requires considerable amount of memory.
- Doesn't scale with its accounts implementation https://en.bitcoin.it/wiki/Accounts_explained (Would love to hear up-to-date information regarding this.)
yes, the accounts feature in bitcoind sucks, but you can get around that by creating your own accounts wrapper around bitcoin. also, bitcoind doesn't crash often if you have lots of ram (4 gb?). That sounds like a decent solution. Would you care to elaborate how such a wrapper works in a high-level?
|
|
|
Like many of us, we have the need for receiving/sending Bitcoin transactions and providing users with an "application balance" in a typical web application that is expected to scale to over 10k+ users and 100k+ transactions. We have been looking at various solutions, but they all seem more or less problematic or not production ready. Node implementationsBitcoind - Apparently not very stable in server environments, requires constant restarts. Also requires considerable amount of memory.
- Doesn't scale with its accounts implementation https://en.bitcoin.it/wiki/Accounts_explained (Would love to hear up-to-date information regarding this.)
btcd - Not production ready. (?)
libbitcoin / obelisk - Apparently fast and reliable, but seems quite difficult to integrate with. (?)
- Does not provide wallet functionality.
picocoin / bitcoinj - SPV implementation, so not suitable for servers. (?)
Hosted / 3rd party solutionsBlockchain - {"error":"Wallets are currently restricted to 5000 transactions"}, nuff said.
Bits of proof - Not production ready. (?)
Node + Wallet separationIdea is to use separate solutions for blockchain notifications and wallet functionality. For verification and sending you run a node yourself or use a 3rd party provider. For wallets, I'm really curious if and how deterministic ones, such as the ones provided by Electrum and Armory, work in server environments. Feel free to suggest other solutions and share your experience. Any advice is welcome!
|
|
|
Quick question I didn't find an answer to: Is there a (subscribable) callback mechanism in Bitcoind for new tx or do you need to use polling? How do you typically solve this, if you need to push the available funds to the user when their deposit clears out?
|
|
|
I'd invest in regular time intervals, like a day or a week. Say you want to invest $10k. Split it evenly and invest $2.5k every Friday, regardless of what is happening on the market. The idea is to bet on the long-term trend and by distributing the buys, you average out the volatility. There's probably a financial term for this simple strategy. EDIT: It's called Dollar cost averaging http://en.wikipedia.org/wiki/Dollar_cost_averaging
|
|
|
In the fear of an exchange getting hacked and busting, I moved over 100 BTC from there to a cold storage for longterm. I generated a single address with the bitaddress.org tool in offline mode with BIP38 encryption + passphrase.
Now that the address contains the 100 BTC, I just wanted to make sure the private key and passphrase are correct so I can sleep my night well.
I obviously don't want to move the bitcoins back "online" just to verify, since that would be counterproductive. But is there some way I can simply check , preferably offline, that the public address, encrypted private key and the password are all correct and I'll be access the Bitcoins in the future?
Thank you!
|
|
|
We are researching hosting of bitcoind for Bitcoin payments. According to https://en.bitcoin.it/wiki/Accounts_explained, accounts do not scale to thousands of accounts with tens of thousands of transactions due to the lack of indexing. What is the current recommendation regarding this and does the above limitation still apply? Is it best simply to "skip" accounts and use the default account for everything? Or simply go with accounts, avoid certain calls and move critical things to the application layer?
|
|
|
Say, a person says he owns 100BTC in certain addresses / wallets. Is there a way to verify the ownership without asking the owner to jeopardize his coins?
I'm thinking about developing a casual website that would allow Bitcoin users to brag about their wealth, but I'm not sure if it would be possible to verify that the users actually own the Bitcoins they claim to have.
Yes, get them to send 0.0000<random number> to your address Most of the people have their Bitcoins in wallets spread across multiple addresses, right? How would a single tx be sufficient to verify the ownership? This wouldn't work for paper wallets either, right? I guess this problem applies to verifying by signing as well. Also, I'm not sure how well signing is supported by hosted wallets and how well Bitcoin users know this feature. But signing would work for paper wallets, correct?
|
|
|
Say, a person says he owns 100BTC in certain addresses / wallets. Is there a way to verify the ownership without asking the owner to jeopardize his coins?
I'm thinking about developing a casual website that would allow Bitcoin users to brag about their wealth, but I'm not sure if it would be possible to verify that the users actually own the Bitcoins they claim to have.
|
|
|
We are in the process of designing a new Bitcoin powered game. We are looking for approachable and practical advice on the following: - What different solutions exists and what are their tradeoffs to handle Bitcoins (bitcoind, blockchain api, etc.) - Generating unique addresses - Receiving BTC - Sending BTC - Security / Server architecture - Provably fair We are basically trying to get a rough understanding what is involved and what should be considered ideally from an experienced developer. This would simply involve giving advice to your best knowledge in the spirit of "do this, don't do this, consider this". I'm happy to pay 0.2 BTC for the consultancy. Please PM if you are interested to help! I understand that trust is a concern. I recently kept my word and paid 0.5 BTC, see https://bitcointalk.org/index.php?topic=306389.msg3294392#msg3294392. I'm happy to answer any questions you might have. Thanks! I hope you don't find anybody for that price, because what you ask for, likely to build up a new service/game, is worth much more than 0.2BTC. Hi and thank you for the feedback. What we are looking for is general advice around these topics, something you could probably fit into a few paragraphs. The security and server architecture is mostly concerning hot/cold wallet implementation and what should be considered if you run bitcoind yourself (memory consumption/leakage, stability, cpu and disk i/o, etc.). I feel someone who has already taken this path himself could rather easily share the wisdom gathered along the way. Regardless, you can suggest an appropriate fee for yourself, if you'd like. EDIT: Ah, the title might be a bit misleading. I've updated the post.
|
|
|
We are looking for approachable and practical advice with incorporating Bitcoins to a game. We need to receive and send Bitcoins similar to how many gambling sites do it. There seems to be a few different solutions, like running bitcoind or btcd, or relying on 3rd party APIs like Blockchain. But there seems to be some tradeoffs between these solutions. We are looking for a short summary between these to help us choose the proper solution. The game also has a chance element and we need to make it provably fair. A general description on how a game can be made provably fair would be appreciated. We are basically trying to get a rough understanding what is involved. I'll pay 0.2 BTC to the first person who gives us a kick to the right direction. If you are interested to help, PM the answers to the above questions! I understand that trust is a concern. I recently kept my word and paid 0.5 BTC, see https://bitcointalk.org/index.php?topic=306389.msg3294392#msg3294392. I'm happy to answer any questions you might have. Thanks!
|
|
|
What you need to understand is the concept of change addresses. A bitcoin transaction consumes one or more previous outputs (coins sent to you) as inputs. It's impossible to spend part of an input, the same way that you couldn't cut off a piece of a $100 bill for payment. You'd need to spend the entire $100 bill, and you'd get change back. The way this is handled with bitcoins is that the transaction that spends one or more previous input, if the wallet doesn't have "exact change", will have more than one output -- in other words, you're sending bitcoins to two different places. There will be an output in the amount that you sent, to the address that you specify, and there will be an output back to you, which is the difference between the outputs that you spent and the amount that you sent to somewhere else (plus the fee, if applicable). The output back to you is sent to an address that Bitcoin-Qt automatically generates, and is not shown to you. For that reason, with paper wallets, once you've imported the key into a wallet, that paper wallet should be considered useless and be destroyed, because once you spend even part of it, the remainder does not necessarily stay in the paper wallet, but is transferred to a client-generated change address. Change addresses that the client has generated will not be shown in the interface. If you'd like to confirm that a change address belongs to you, you can use the "validateaddress" RPC command in the debug console, which will return "isMine":"true" or something to that effect. I highly recommend that you read the wiki's article on change, https://en.bitcoin.it/wiki/Change, for more detailed explanation. Now, to your situation. It seems to me that your paper wallet was not funded all at once, but rather in several smaller transactions of a few bitcoins each. What happened here is that after you imported the key from the piece of paper into your wallet, when you sent the small transactions, it spent some, but not all, of the outputs controlled by the paper wallet's key. The remainder of those outputs were transferred into change addresses within your B-Qt wallet. Three outputs, in the amounts of 4.8926 BTC, 0.00945727 BTC, and 0.008 BTC, remained unspent. Those outputs were swept up by Coinbase, and transferred to them. In the meantime, your client believed that it had ~10 BTC available to it -- ~4.91 from the paper wallet's key, and ~5 from the assorted other keys in the wallet, including those change addresses that I mentioned. Presumably the client was offline at the time that the key was swept by Coinbase, and subsequently was started, and then while it was still busy syncing and catching up to the network, the bitcoins were sent in a transaction to Coinbase. The client, not having been up-to-date enough to see the paper wallet key swept by Coinbase, didn't realize that those outputs were no longer unspent, and tried to spend them along with the other coins that it did have control over. This transaction was rejected and not relayed by other nodes, which see it as an invalid transaction, since it's trying to spend coins that have already been spent. Now, your client will continue to hold on to this transaction in its wallet and try to rebroadcast it periodically, to no avail. What you need to do is clear that invalid transaction. If you're willing to lose metadata (address labels, etc) attached to the wallet, you can start Bitcoin-Qt with the -salvagewallet flag, which will cause it to make a new copy of your wallet, transferring over only keypairs, and leaving behind everything else, which includes the transactions. At that point, it will perform a rescan, and scan the blockchain for any relevant transactions. Once that's done, it should show your correct balance. This is probably the easiest way to solve your problem. Other possible ways would include editing the wallet file (it's simply a BDB database) to remove the invalid transaction, or manually creating a transaction that will spend the outputs that are currently locked up in the invalid transaction. Thank you for your lovely and approachable explanation. I started the client with `/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -salvagewallet`. It's still syncing with the network, but it looks promising as it's now showing a +4.9315 balance! Just to make sure: The balances in the wallet and in the Coinbase are now completely separate and I'm free to spend them however I wish? I'd gladly pay you the 0.5 BTC award. Could you kindly provide a payout address?
|
|
|
I'm upping the reward to 0.5 BTC. This is taking way too much of my time.
|
|
|
Google/Chrome history from Apr 17th shows the following relevant searches I did: 16:08 searched "bitcoind" 16:09 visited "Running Bitcoin - Bitcoin - Bitcoin Wiki - bitcoin.it" 16:09 searched "bitcoind mac os x" 16:10 visited "Best BitCoin client on Mac OS X - Bitcoin Forum - bitcointalk.org" 16:15 searched "bitcoin clients" 16:15 visited "Choose your wallet - Bitcoin - bitcoin.org" 16:23 visited "Bitcoind - Bitcoin - bitcoin.it" 16:26 searched "bitcoind mac os x" 16:26 visited " http://multibit.org/" 19:14 searched "v7 import bitcoinqt" 19:14 visited "How to import private keys - Bitcoin - bitcoin.it" (At this point the two tx happen) 19:35 1NRYDFxtYCwHXam32yFAn8kpiWfdx4XefX -1.37BTC 19:49 1VtaJTXABVbrZKxFYPXUg3iGMS5mxBXxB -3.56BTC I believe the times are in EEST (UTC+3). So if I'm analyzing this correctly, just before those two transactions (imports?), I was googling about importing private keys. Maybe this will hint off to the right direction.
|
|
|
|