|
As was noted by Danny having more connections is not really going to help wrt the speed of obtaining blocks - in fact limiting the connection to just a single one (that is the fastest you have a connection to) would probably be better for that purpose.
Having more connections is only really better in that it makes any sort of "spoofing" attack a much more difficult proposal as well as increasing the general size/strength of the Bitcoin network.
|
|
|
|
Well I was implying, 1/2 green:4 & 1/2 orange coins,
1 green & 4 orange coins, etc.
And all the time I've been thinking that bitcoins are digital "gold" not digital "fruit". :> |
|
|
|
I think the problem is the tying of "number of coins" image with donator and with post count - it's already bad enough that a "newbie" can donate 10 btc and suddenly look like a "hero" but with this idea people with hero post counts (not that I think large post counts are at all something that really counts) suddenly will look like "newbies" unless they fork out more cash. Perhaps would indeed give the forum more btc in donations as all those donators rush to get back their 5 coins.  I am assuming you are going to donate enough to have 4 1/2 green coins (from your own list you won't be able to keep your current 5 coins). |
|
|
|
I have heard some people who have generated really large numbers of addresses (tens of thousands or hundreds of thousands) complain that the bitcoin-qt program becomes unusably slow when you have an excessively large number of addresses in your wallet. So "no limit" might be a bit subjective.
True - and of course as in any software system the term "unlimited" is always limited (by memory and patience at the very least).  I also recall reading something about the next release having some changes that will help the "large number of addresses" problem (although I haven't got a link - you there Stephen?). |
|
|
|
|
Each time a change address is needed (which will generally once per tx) then it will be taken from the wallet address "pool" (the size of which by default is 100) with a new entry being then added to the end of the pool.
Thus until the original pool has been exhausted (i.e. after 100 addresses whether explicit or change ones) your old backup will be fine. Note that you can adjust the pool size to make it bigger (say 1000) if you think that 100 is too small for the number of tx's you are doing and the frequency at which you take backups.
There is no limit to the total # of addresses a client will create (just the pool size as described).
Unfortunately in the Satoshi client you have no control over the change address unless you want to use the console and play around with the raw tx API (not something for the feint of heart and an easy way to lose a lot of btc as tx fees if you don't know exactly what you are doing).
|
|
|
|
|
Just to update I did get a reply to my PM to Erik and they are going to get someone to look at this in the next couple of days (will update this thread again after that).
To be fair to Coinapult the whole Thanksgiving thing had skipped my mind and was happy to get the message from Erik.
|
|
|
|
Cryptoxchange is a well established website. I hope they don't follow the path of other exchange companies...
Maybe you missed the news - the owners are currently in the process of shutting down this exchange service (and I think it says as much on their website's main page). |
|
|
|
Perhaps some sort of special script op code could be used to determine that a tx output is only valid if say the subsequent nth block number's hash's high bits are equal to a value (with both an AND mask and a value). The protocol would need to be changed to handle this special script output and it should probably not be valid until the block height is equal to the checked block height + x blocks (to avoid confusion with re-orgs). It really isn't much different to the time delay feature - just would need a couple of extra numbers: int64_t high_bits = get_high_bits_from_block_hash( ); // nothing special needed for this
...
if( tx_output.check_high_bits ) // tx would need these two new values
is_valid = ( ( high_bits & tx_output.check_high_bits ) == tx.high_bits_value );
Actually I guess it might even be simpler to just use the "nonce" rather than part of the hash. |
|
|
|
|
Oh - shit - yeah - being from Australia and living in Beijing I forgot all about that.
Well hopefully will hear from someone early next week then.
|
|
|
|
A few weeks back I sent 1 BTC via Coinapult to my nephew and all seemed to go fine (i.e. the email was sent), however, he only got around to installing a Bitcoin client the other day and when he went to the site to try and redeem the 1 BTC it reported the balance as being 0 BTC.  He sent a support request (which hasn't been responded to in now over 48 hours) and I sent a PM to Erik (which hasn't been responded to for over 24 hours) with the relevant tx id. Some support would be appreciated to work out what has happened to the 1 BTC (unfortunately not the greatest first experience for someone to have with Bitcoin which now makes me hesitant to recommend Coinapult for such purposes). |
|
|
|
|
CIYAM will soon be releasing a completely new project funding system (entirely based upon Bitcoin) that combines non-refundable "donations" that can be specifically targeted to a single task as well as git pull requests successfully merged "escrowed" donations that are refundable if the pull request is not merged by the given delivery time.
There is a lot more to this project (and over 250K LoC so far) which will be open source (under the most unrestricted license that I can use) so if you are interested in this project please feel welcome to PM for more details (at the very least it may save you a lot of development time).
|
|
|
|
|
I read in another thread that apparently the main guy behind CryptoXChange has been very ill recently so a little patience might be required (in my dealings with them I have never had any problems so hopefully the shutdown will go smoothly).
|
|
|
|
listunspent output is designed to be read by machines, not people, and its output is designed to go directly into createrawtransaction.
If you need all the human-friendly details of a transaction, use getrawtransaction <txid> 1
Thanks Gavin - I hadn't realised I could do that (although it is one extra step it should be easy enough) - understand that I need to know the address (if present) as my raw transaction needs to include that as the "change address" (yes - am not wanting to be anonymous at all with this use case) so indeed I am wanting to automate this but the "machine" still needs the address. I'm against adding "address" to the listunspent output, because most of the time it will be unused and sometimes it would just not appear at all (because not all scriptPubKeys are bitcoin addresses).
I understand - but it would make my job as a developer easier if I could just make one RPC call rather than several (as I need to find a specific address that I am going to create a raw tx to send coins to another address with change being sent back to itself). |
|
|
|
Okay - after mulling over your hex hints I worked out that from: "scriptPubKey" : "76a91406c1991c6466a550b66931ea48970cfd17ff51b388ac",
if I remove the 76a914 prefix and the 88ac suffix then I get 06c1991c6466a550b66931ea48970cfd17ff51b3 which if convert to base58 using brainwallet.html (as there doesn't seem to be any standard Linux program to do this conversion and I don't use PHP) I finally get 1ciyam3htJit1feGa26p2wQ4aw6KFTejU. That is really a PITA - I guess I could write my own program to do this, however, I really hope one of the devs is reading this and might consider adding the following to the listunspent outout: "scriptPubKey" : "76a91406c1991c6466a550b66931ea48970cfd17ff51b388ac",
"address" : "1ciyam3htJit1feGa26p2wQ4aw6KFTejU",
|
|
|
|
1) No idea. I've never felt like it was "missing" as such, and I've done quite a bit with raw transactions. It is trivial to figure out the address, when one exists. A normal sendtoaddress transaction will start with 76a914 and end with 88ac * (both in hex), with the pubkey in between, and from there it is just a matter of hashing and base58check encoding. A P2SH address will have a different scheme, as will a generate transaction.
Sounds like you are a lot more familiar with the inner workings of Bitcoin than me - but how exactly (say from a bash shell) do I get the hash of the public key and base58 encode it (which is why I thought bitcoind should do this for me)? 2) the output section of createrawtransaction is a list, {"address1":"amount1","address2":"amount2","address3":"amount3"...}.
Thanks for that. |
|
|
|
|
I have just started playing the the listunspent/createrawtransaction/signrawtransaction/sendrawtransaction RPC commands which work great, however, there are a couple of things I am wondering about.
1) Why doesn't the listunspent include a bitcoin "address" as well as the public key in the JSON output (as I can't easily tell what is what when I'm looking at that without jumping into blockchain.info to look up the tx)?
2) If I want to send to more than one output address with createrawtransaction what is the exact syntax (an example somewhere in the docco would be nice)?
|
|
|
|
|
Most likely no such trades actually occurred (had read in another thread that prices have shown up there that never actually went through as trades).
|
|
|
|
|
Just from the lack of trading volume (ever since it started really) it was fairly obvious that this company could not even afford to pay for one full-time skilled employee (which would explain why the severe lack of service).
Unfortunately I think Aussies are just not quite ready to buy/sell bitcoins in large enough quantities to justify having an Aussie focused exchange (hopefully this will change down the track).
|
|
|
|
If you guys hadn't noticed the following is now on their main page: Crypto X Change,suspending trading and returning client funds.
|
|
|
|
|
Show Posts
