2 x 1964 Canadian 80% silver dollars - .6 Troy oz of silver, 1.2BTC each
1 x 1958 Canadian 80% silver dollar - .6 Troy oz of silver, 1.2BTC
1 x 1922 American 90% silver dollar - .77 Troy oz of silver, 1.54BTC
Are your prices still good? |
|
|
|
|
Hi
I would be interested in the 90% halves. Are these Libertys (1916–1947), Franklins (1948–1963) or Kennedys (1964)
Do you also ship these internationally?
|
|
|
|
|
I am not sure if this has considered, but any Xcoin without some kind of solid (no pun intended) 51% protection that relies solely on CPU hashing would be at risk due to the availability of cheap cloud instances (i.e EC2, etc)
|
|
|
|
I've tried once to compile it. Gave up.
I don't understand why can't you bundle all the needed libraries and distribute the complete source code with the client?
1) You will get more trust. What's the point of doing code review if you can't compile a binary version from it?
2) You will get more developers involved. I, personally, can't spend several days, figuring out just how to compile it. But if it were a matter of loading it into VS and hitting Build, I might work on small features or optimizations.
And the most annoying is that I don't see any rational reasons not to do it! Why hasn't it been done from the beginning? Are you trying to impose some sort of an artificial "entry barrier"?
P.S. I am specifically talking about Windows.
+1 on this |
|
|
|
I'm kinda curious who (and why) would ever run a real accounting based on the bitcoin's wallet.dat. The implementation here is obviously not compliant with anything that would be considered a GAAP (Generally Accepted Accounting Principles). I understand that some people will fly-into-the-night rather than face an audit, but is there anyone planning on running a real business that is going to have a real audit trail in their accounts?
The "accounting" term that is referred here is not your standard GAAP. But instead is an implementation to track balances in bitcoin "accounts". This is especially usefull when building shared services like wallet |
|
|
|
|
I am unable to run this in Windows Server 2008. It opens up for a few seconds and then just shuts down. Event log viewer shows the following error
"Faulting application name: bitcoin.exe, version: 0.0.0.0, time stamp: 0x4d44aa00"
|
|
|
|
I've actually always wondered why the "move" command actually allows negative balances.
Was there someone thinking of a possible use for that, like, dunno, maybe some kind of "ledger"?
Or was it a decision like not wanting to interfere with whatever possible uses an application developer could find?
I guess i'd personally like to have a configuration option to make bitcoind only accept positive account balances.
Yes, I had the same question too. At first i thought it was an error on my end that the move allowed negative balances. Given that the accounts features is used as an internal ledger I would have assumed that move command would not allow negative balances. If this is by design one possible reason that i can think of is due to optimization perhaps? (so that the getbalance check would not be executed before the move is allowed) |
|
|
|
This is unacceptable. I have mine configured as well with paytxfee=0.0 and yet transactions I put through bitcoind on command line or with json rpc are applying a fee.
I just put in a transaction 73c294e732dac0b0cfe2da6633aec7cd66616d4b9f9e27b629bda31f8d8e1f5e for 0.0192 which generated 0.0005 in fees. We need to be able to block the user from making a transaction that will put their account balance negative. To me this is a pretty serious bug, that I've told it to send no fees and yet its sending fees instead of throwing errors.
I felt the same way when i first figured that out. The bitcoin client would warn you a impending transaction fee but when sending from command line (bitcoind) it does no such thing. As such from a commerce point of view this can get tricky, which 0.0005 is small amount but from what i understand if the transfer is large enough its possible to incur higher transactions fees which would kinda of suck. I would propose that you could put in place a fixed transfer fee for all transactions (i.e 0.001) if you are running a free service or absorb the transfer fees if you're running a "for-a-profit" operation as part of doing business Cheers |
|
|
|
Hi I have a question regarding the bitcoind command line parameters. I noticed in some of commands there is [minconf=1]. I know this stands for minimum confirmations for transactions like listtransactions, listreceivedbyaccount, listreceivedbyaddress,etc. But for other commands like "move" and "sendfrom" which are basically internal accounting transfers what do these represent? Why is there a need to the [minconf] here. For example move <fromaccount> <toaccount> <amount> [minconf=1] [comment] sendfrom <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to] Thanks |
|
|
|
The stale rates are quite high. I am getting around 30% on a private pool.
I've been pointed to a thread where Bitcoind optimizations for pools are being discussed, and will likely try to monkey some of those into geistd this weekend or so (maybe earlier, I'm sorta on the move now). I would be very grateful if you agreed to carry out some testing of that branch (assuming I get it work, lol  ) via your private pool. If you put this up somewhere, I would give it a go. But for the moment i am back to BTC because the stales are quite high. You should perhaps look into getting some public pools setup. Cheers |
|
|
|
|
The stale rates are quite high. I am getting around 30% on a private pool.
|
|
|
|
|
As an alternate suggestion, we can use DNS txt records tied to a domain name. Similiar to sender identification systems like OpenSPF. The client can be built to lookup the DNS Text records of the domain name, search for the corresponding entries and send to this address. This approach would also eliminate any kind of centralized lookup system like first bits (I have nothing against this service but merely used as an example) and domain administrators would have individual control of the their entries an example entry would look something like this:
"c=btc 1btcaddressXXXXXXXXXXXXXXX"
"c=slc s1btcaddressXXXXXXXXXXXXXXX"
etc...
Using this approach you could tell someone to send you a payment at mydomain.com. And if it would be possible to attach comments to transactions then they could be differentiated. In addition its also possible to rotate the addresses every X days by changing the TXT records for additional privacy
cheers
|
|
|
|
|
Nice, simple and usefull site. +1
|
|
|
|
|
On the topic of scalability, would setting -connect=xxxx.IP help in offloading some of the processing? If it does then we could setup a dedicated node to connect to
|
|
|
|
Looking at the various arguements brought forward, I am going ahead with the "let bitcoind manage" the transactions approach using the "Accounts" feature as a means of storing balances. At the moment I'd rather deal with scalability issues vs having unscynchronized balances between a separate DB vs wallet.dat.
If you want to scale really big with this approach you need several servers each running bitcoind, and each managing their share of accounts. A load balancer for this setup is fairly trivial to set up. Load balancing is definitely one method and it has crossed my mind, but that would defeat the "move accounts" feature that provides instantaneous transfer for users within the system (same wallet.dat). Having multiple bitcoind instnaces and moving counts from one wallet to other would also create additional network transactions in addition to delays required for confirmations. |
|
|
|
|
Looking at the various arguements brought forward, I am going ahead with the "let bitcoind manage" the transactions approach using the "Accounts" feature as a means of storing balances. At the moment I'd rather deal with scalability issues vs having unscynchronized balances between a separate DB vs wallet.dat.
There does not seem to any performance metrics as to what would constitute an upper limit for storing transactions in the wallet.dat. I have tried running some simulations by dumping more than 200k "move" transactions into the wallet and so far it appears to be running fine. I am assuming that the hardware in use would also play a critical role as to how far this would scale. However, the real tests would be concurrent use.
Thank you for all your suggestions and if may add this in as a feature requests (somewhere down the long list), it would be nice to be able to store the transactions into a separate DB i.e odbc, mysql, etc
Cheers
-MT
|
|
|
|
I'd take a look at this thread: https://bitcointalk.org/index.php?topic=25094.0This fork makes it easier to poll/import transactions into your own DB and then do whatever you need with them rather than relying on bitcoind to keep accounts straight. I'm using it for my own purposes (though I'm not accessing it from PHP but Python; I still need to keep track of transactions in a RDBMS). Thank you for the tip. However, all things being equal I would prefer to stick with the mainstream releases |
|
|
|
Can I ask why you don't want to use your own code to manage balances and transactions? It seems to me that you need to do those things anyway, at least in most scenarios that I'm familiar with.
By having the bitcoind manage the balance and transactions I could avoid any synchronization and integration issues. This would also simplify the development process |
|
|
|
|
From what i understand you are going to have to work backwards. Send the transaction first, then do a look up using the txID info to see if a fee has been applied.
Cheers
|
|
|
|
|
Hi Gavin
Thank you for taking the time to reply
Any suggestions as to how one should go about this then for high volume transactions? I've looked at the previous posts and wiki entries, most of these points towards using the "Accounts" feature. If the transactions were recorded to an external database, the biggest issue i see with this is polling the addresses when a payment is expected and also dealing with redundant payments.
Thanks
-MT
|
|
|
|
|
Show Posts
