I'd be willing to buy the coins you will eventually generate right now at below market rates. 2000BTC on Christmas (date negotiable) for $100 right now? Will you generate or receive donations for plenty more than that?
Hmmm, that's an interesting concept... I don't really like futures negotiation, it's not in my culture if you will. But the thing that I wonder about is how to actually control that, I mean, I know I'm honest but if between now and Xmas I don't generate a single coin (unlikely but still a statistical possibility) what would happen then? I'm doing this because it's a lot of fun for me, I love the challenge, and I'm not trying to cut any profit, but while it is really hard to establish an honest reputation it takes little more that a little misunderstanding to be stuck with a dishonest one. I'm open to such an agreement but only under the understanding that things may go sideways, I may have to stop working on this (though I already have a good part of the work done and disclosed) and I'm not going to take this as some kind of contract binding me to do this by a set date... And as for generation, yes I hope to generate much more, based on my current stats. Donations I expect at least 10 times what I got so far with the CUDA code I've provided, which roughly adds up to... 0.0000  That is why I'm trying to sell the coins, man. |
|
|
|
Well, I want to continue to pursue this CUDA thing, but funds to diverge to that are scarce, so I thought I'd try and get a little help from the community, in the form of an auction of sorts. I need to spend something around US$400 on hardware, which I will anyway, but in an attempt to reduce the impact of that in my very own personal economy, here's what I though; I have 2000 BTCs that I'll part of (though reluctantly) to help on paying for things, which at mtgox would net me ~US$120... very far from the target. Would you like to buy some, at a higher than market rate? I'll take paypal transfers for whatever amount you care to buy, assuming you are the highest bidder. If there are no takers, no problem, I'll work on this still and will release all my work MIT licensed just like bitcoin client. If I get more than I ask for, I'll even develop an opencl version for all you ATI users out there. If I get less or just enough, I'll polish the CUDA version I have so it detects cards and works with more than one if available, so you can build your very own Tesla based super bitcoin miner 20 blocks of 100 coins, from here to Sunday, place your bid for nr of blocks and price per block! Obviously I'll also take coins as donation, but I will not give anyone earlier access to code, or any of that, and I do no promises as to how much time I'll be able to dedicate to this, of course. |
|
|
|
|
Kudos to you!
I will have to find the time to merge this into my private version, but this opens a whole new world of possibilities to me, in terms of code organization mainly.
|
|
|
|
|
Thank you!
Yesterday I've built on linux for the first time (I don't do GUI though) and it was a breeze. So anyone that has a cuda enabled device but doesn't want to use eurekafag's binary should have no trouble getting it compiled, but if you can't/won't, then major kudos to eurekafag for putting this out.
|
|
|
|
Ну-с, вот собрал небольшой пак из демона и графического клиента. Всё-таки удалось уговорить wxWidgets и биткоин подружиться, причём, статически. Размеры вышли чуть больше, чем у Сато, не знаю, почему так. Вроде, пострипал, и дебаг не включен. В общем, кому охота, налетайте. Единственная тонкость: после использования этого клиента стандартный биткоин перестаёт понимать базу (выдаёт пару ошибок о необходимости её починить и вылетает). Возможно, потому что я собрал с более новой Berkley DB. Так что в любом случае сделайте бэкап. Sorry for the english request on the russian lists, but if people are using my patch I would really appreciate all feedback you could give, and patches to make it work in other OSs. Please post comments that might be of use to the community in general in the original english thread if at all possible. Thanks! |
|
|
|
|
Why did you loose interest? That should get the discussion started. Also, what is it you were looking for in bitcoin that you need an alternative for?
I use bitcoin because I'm very interested in a 'deal facilitator'/commodity/whatchacallit that is not centrally controlled, thus not regulated by a single entity. Sure, someone with a huge amount of coins (artfonz, satoshi) may tilt the balance, but only once if there's enough critical mass to absorb the coin input.
What about you?
|
|
|
|
|
satoshi et al: I have been thinking long and hard about security of the wallet, as I implement other web services that will (I hope) move larger sums of bitcoins. The backup wallet is great, I'm now doing automated backups every time I create a new address, including on sending transactions.
But will this scale on a site that sends many transactions? I always have to backup the whole wallet, and that takes addresses, key, transactions, and grows considerably with usage. For more intensive usage I believe either less backup points or better separation of data is needed.
The two simple solutions I can think of for this are:
1) separate addresses/keys from everything else, so it is easy to do incremental backups or at least limit the backup size to that really needed to recreate the funds in a hardware failure event.
2) implement what has been talked as a future feature, the ahead of time creation of address bundles to be used, so one backup of the wallet is good for 1000 future transactions, or something like that
2.1) to use this efficiently, one should have the possibility to query how many addresses are still left in the unused pool and request creation of a new batch if needed so backups can be timely created and we drop to 0 the possibility of loosing data between address creation and backup
Of course doing both 1) and 2) would be perfect, but can we expect any of the above for a future release? Should we start hacking our own patches?
|
|
|
|
|
This has been discussed in many other threads, but it might be a good idea to do again, to avoid misunderstandings.
The reason, as far as I understand, for the above stated is change. When you send coins, one or more transactions received and emptied, but that may not sum up to the exact transfer amount, so a new inbound transfer is created with the change. This will be a new address for you, and thus not backed up before. Imaging:
addr1: 50BTC
addr2: 2.5BTC
addr3: 50000BTC
All this is backed up, now you send 60 to me, and end up with:
addr1+addr2+addr3 -> TX (50052.5), broken in
myaddr: 60 (transfered to me)
addr4: 49992.5 (your change)
So a new address is automagically created for you, and all your coins put there. This was not in the previous backup, so if you loose this wallet... you are hosed!
|
|
|
|
I read the wiki and it says the interface only accepts requests from 127.0.0.1. Is this still the case? Is there a setting to override this?
This is still the case and I don't believe there is a setting to override it. It's hardcoded in the source. Instead of writing a 'proxy' app you can use SSH to tunnel. For example, if your bitcoin instance is running on 'example.com' and that machine is running an ssh server, you can tunnel to it from another machine with: ssh -N example.com -L 9481:localhost:9481 Now you can use the RPC interface on your local machine to port 9481 and it will be tunnelled over an encrypted SSH session to the machine running the bitcoin RPC server. You want to encrypt the connection because the JSON-RPC password is sent in clear text (it's actually base 64 encoded but basically it's the equivalent of clear text). Can you compile your own bitcoin? The latest svn has an option to allow binding to other interfaces, not just localhost. If not the next version (0.3.13) is supposed to have that. |
|
|
|
|
I have added ssl to bitcoinsportsbook.com and you'll all get redirected to https when you visit the site. Let me know of any problems!
|
|
|
|
2 confirmations take a min or two min. the more confirmations the better.
Huh? Why not say it takes 1 second? Hehe, two confirmations take 2 blocks' time. The expected average is 6 blocks per hour, but that doesn't mean there will be one block every 10 minutes, rather difficulty increases every now and then based on the average blocks created in the last iteration. It really is impossible to define a specific timeline, but the client does get almost immediate notice that a transaction is on the way. If it trusts that information blindly and is thus open to double spending attacks, or it waits for as many confirmations as it sees fit depends on you, the developing party, but two blocks in a min or two I don't think I've see so far |
|
|
|
Consider this-- bitcoin generation is a lottery of sorts where the price of the ticket is the fixed cost of the hardware and software plus the electricity to generate X khash/sec. Currently this price is measured in dollars and the winner of the "lottery" is rewarded in 50 bitcoins. I know it's not in the spirit of bitcoinery (?), but what about designing a lottery similar to TAABL where tickets are bought using dollars and the winner of the lottery is rewarded in bitcoins?
If I'm thinking about this correctly, if you designed the rules of the jackpot correctly, the price of tickets for a 50 BTC payout should converge toward the cost of generating a block minus the edge paid to the house.
I don't get it. So people would buy in to collect the 50 BTCs from each generated block by the "lottery" site? If not, where would the 50 BTCs come from? One of the features inherent to taabl, as I designed it, is to become as insulated from "money" as possible. It deals with bitcoins, and nothing else, because otherwise we are talking about a full blown gambling site subject to whatever laws and regulations exist, and that is one mess I do not want to get into |
|
|
|
Yes, there are risks to both, upside and downside.
To buy all BTC or a huge chunk anyway the price will rise a lot , probably 0.5 $ per BTC is not too far fetched
To avoid this, some trading rules would make sense, i.e. limiting BTC possession to a certain percentage of all BTC available. Otherwise someone can easily corner the market.
I could even do it.
Are you talking about market regulation on a site level or globally. The latter, to be possible, would imply changes to the protocol and frankly changes that would remove some of the benefits of bitcoins, like the pseudo-anonymity. |
|
|
|
This scheme is also stupid because it will make businesses and individuals more vulnerable to criminals and industrial espionage.
Is that 'criminals' in the popular sense or do you mean 'the government'... Scratch that, it's as redundant as it gets |
|
|
|
not worried. Even if he has 25% now, he won't have 25% in the future unless he's generating 25%.
Which it is rumored he is... that is, until someone gets GPU mining mainstream. I have volunteered myself to do it, but I lack the hardware and don't want to put both work and money into this. There has been a couple of members of the forum that have agreed to send me coins for GPUs or the actual GPUs, but in the end, it never happens, so either some coder with time and hardware does it, or artfonz and a few others will hold most of the processing power for some time still. |
|
|
|
Separate "accounts" (addresses with labels) to accumulate Jackpots is the right idea. Users buy tickets, bitcoins are moved to the appropriate Jackpot account. When a Jackpot is won, transactions flow out of its account back to whoever won.
Yeah, it is quite obvious. I suffer for over optimization obsession syndrome I feel that as data flows only inside the application there's no need to register transactions and put that 'extra load' on the system, but quite frankly the extra load is perfectly ignorable, and the transactions help keep everything tidy. Are you planning to do anything on this regard? I'm sure I can find my way around to do it myself, it will just take time, but I don't want to duplicate any work though. |
|
|
|
|
I sure hope all the US based companies are quick to comply, or a new "terrorist threat" will suddenly appear, some country gets bombed and that will serve as justification to force everyone into wanting this because, you know, it's in everyone's best interest, it's the national security that is in stake.
That, my friends, is the problem with democratic dictatorships.
|
|
|
|
The "label" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.
If the API was extended as I describe below, would it solve the same problems as having multiple wallets?
Proposal:
+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>
(change generated would be automatically tagged with <label>)
+ add optional [label] param to getbalance.
+ new method: listsentbylabel
(returns array of [ "address" : "bcaddresssentto", "amount" : x.yz, "confirmations": n ])
Each customer "account" would be a bitcoin <label>. Account handling would look like:
Create account / create new address for account:
getnewaddress [account_id_label]
... tell user "fund your account by sending coins to {the address returned}"
Customer withdraws/spends:
sendfrom [account_id_label] [address] [amount]
(FAILS if balance for that account too low)
Show customer their balance:
getbalance [account_id_label]
Show customer their transactions in/out
listreceivedbylabel [account_id_label]
listsentbylabel [account_id_label]
---------
Seems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer. At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.
That is a much better approach, agreed. Assuming one label spans multiple addresses, so a client can accept transactions from an imported priv key (this being discussed on another thread), it seems to fit my needs perfectly, with only one small caveat which is internal transfers; say I use this approach for the lottery users (though that is not my use case, I actually would be more about site separation than user separation, but still): - Each account has on inbound address, annotated with the login label - Every time a user withdraws, I use the sendfrom mechanism you describe - The user hits the jackpot, but the prize is actually held in multiple users' accounts so a) I need to, when users buy tickets, move the amount to a separate address (forces external transaction, sucks) b) I leave coins where they are, and then on payout I make a normal sendtoaddress (both external transaction and breaks the label accounting logic) c) I leave coins where they are, payouts do nothing to the wallet, withdrawals do as many transactions as needed from each user account (what a nightmare!) I don't see any good option here, and the best one, if I'm doing external transactions anyway, is a). I can trust these transactions with 0 blocks confirmed, because I'm both the sender and the recipient, and this would keep the accounts/labels in check, which serves as a great verification to the overall balances. Can you think of any alternative? |
|
|
|
I just tried your latest patch. I noticed a few things: - Your post, and the patch name, makes it seem like the patch is against revision 157, which does not yet exist. Upon looking at the content of the patch, it is obvious the patch is against revision 155.
- You have an extraneous curly brace on line ~3077 when FOURWAYSSE2 is not defined
- I get about 6200 khash/s with your patch using the GPU only (limit set to 1 CPU). However without the CPU limit, and using 2 CPUs, I only get 6500 khash/s according to the counter. That can't be right.
Hey puddinpop, I'm curious. On what OS are you compiling this? If it's not OSX, care to share the makefile? Also, what is you graphics card and how does my patch compare to your version on it? I got about 20% increase on mine compared to yours, but then again some things like the threads per block or the total number of blocks have a huge impact on the overal performance, and I didn't try to optimize your version. I'm sure puddinpop has good reasons to not reply to my questions, but it feels weird. It's almost like he has something against me. Do you, puddinpop? Can't we just be friends?  Anyhow, no joke, I have generated my first real block using the CUDA miner! Woohoo, 50 coins accounted for, *now* it was all worth it, the sleepless nights, the complaining family due to my lack of attention, everything! If I get another block I may start developing an opencl version, while I'm in profit! That is, if puddinpop didn't make one first and sold it for 20k coins |
|
|
|
Satoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn I'm sure, Satoshi should better plan documenting the protocol as a standard, so we will have interoperable implementations, free from his dictatorship and tyranny. That is solely my own opinion. For the techical issue discussed: It is clear, that the "node" instance, that holds the blocks database, connects to the network, exchanges data with peers and with users, is architecturally independent from the "wallet" instance(s). Wallet(s) may be viewed as peer(s), that request the block data and publish transactions/blocks, like network peers do now. So it is feasible to have "block chain" daemon, that will cache block database on disk and may also act as an intermediary between the local users and "the network", so it will have no secret keys at all, no sensitive information. And the local "wallets" will have no networking part, no network interoperability problems, except for connecting to the daemon. So there will be no "bind to port 8XXX" issue. They will be free from the P2P stuff, will only work in a client-server paradigm, will trust the server for executing their requests, but will not trust the server with any secret information. And so, they may be as simple, as system-on-a-chip cards, capable of iterating through the blocks/transactions list, but not required to store it. The block chain database may also return narrow results, parameterised by the list of public keys, like "getreceivedbyaddr" does now. Generation should happen at admin's local wallet, not at the networking node. That means "wallets" will be permitted to publish not only transactions, but solved blocks too. For current codebase this is a major refactoring, I'm sure Satoshi will veto on it, and he may have his own merits. So the only hope is the alternative implementations, that aren't possible without the standard. Well put, the standard is certainly needed to move this into mainstream, and source code as documentation sucks. But that is slightly longer, more important goal, not one I will hold off on projects for. I'm sure you agree the standard definition alone will take a good amount of time, especially when people look at it and start saying what if, or wouldn't it be better if... Then we still have to develop standards compliant clients. I'm not saying that effort isn't worth it, much the opposite, it's mandatory for the immediate future. This hack jobs we do are actually a great way to get to know how things are being done, thus gathering any knowledge to help in describing the protocol |
|
|
|
|
Show Posts
