If you use an additional DB at your end (other than core's leveldb) to store blockchain data, what DB do you use?
I use my own solution, based on a hashmap (acting as the index) holding pointers to the records. It makes accessing the db very fast, but needs much more RAM comparing to leveldb or berkeley. Apart from the hashmap index and the records, there is of course also a code for the disk operations - to keep the files in sync with the memory. It's simple and rather archaic, but has been proven to work great for UTXO-db purposes - I would not swap it for any other db engine I know. Although I'm also quite interested in other solutions, which I don't know - there must be some more optimal ways of doing it. https://github.com/piotrnar/gocoin/tree/master/lib/qdb |
|
|
|
Since transaction fees are paid PER BYTE, that means that bitcoins received at the uncompressed address will cost you more in transaction fees.
For future reference, it's also worth to know that segwit addresses (so called P2SH-WPKH) made from uncompressed public keys are (will be) undependable, no matter the fee. They added the extra check in segwit code that blocks spending coins from uncompressed segwit keys. Which I think was a bad idea, but well... you just have to be careful now, making sure that the hash you are making P2SH-WPKH address from did not come, by a chance, from an uncompressed public key. Otherwise you're fucked  |
|
|
|
more sophisticated system could be to use the real block chain and zero-confirmation payments through multisig. like 2of2 with your game's master key and the player's private key, kept like a password seeded something. then it would be like the player deposits certain amount of btc into his profile's btc address. both signatures (his and the game's master key) are required to spend any money from thet address. so once they make a transaction, it cannot be double spent again. not without both parties agreeing on it - solves loads of problems. then, for the player's security, the profile address could be made in a way that after a certain period (e.g 6 months), he can spend these bitcoins with only his signature. it's the new feature that nobody has really used yet, so suit yourself |
|
|
|
|
the central wallet where all the bitcoins are kept and you just keep a record of who owns how much of it, is much easier to implement.
but then, people will be more reluctant to put their money there.
and it will be all your responsibility to secure it.
holding separate wallet for each player is possible, but you might just as well assume that they already have their own wallets.
then only implement some kind of system that bases certain actions inside the game on btc getting deposited to certain addresses. on the actual bitcoin blockchain.
but then, this kind of system is probably not very good for a game, because of the confirmation times of the transactions - they may take hours.
|
|
|
|
Hi folks,
Will segwit soft fork require any changes in mining software for solo mining?
Thanks.
Not until it gets activated, which will be known (and most likely widely announced) 2 weeks before the moment. However, if you don't upgrade, you won't be voting for segwit activation. |
|
|
|
|
FWIW, the biggest segwit block so far on testnet (#894090) is 3876524 bytes.
So, had all of them been as big as that one, it's 144*365*3876524, giving almost 204 GB per year.
Some method of snapshoting an entire UTXO set, at each/certain chain height and broadcasting/distributing these snapshots in a secured way - this is becoming more and more desirable... Not to say necessary.
But after it's finally done and accepted by the network, the blockchain size should not matter much anymore.
|
|
|
|
|
Thanks.
I think I figured it out.
It was the core's consensus lib, which I use for cross-checking scripts (to make sure that my script processor returns the same result).
It was happening for blocks containing txs with 10000+ inputs, so if the script processing function needed extra ~6ms to finish, it was creating the problem.
Not sure whether it is the consensus lib itself (from 0.13.0) that is slow, or is it rather the (slow) way my app's engine calls the external dll...
Can't say, but after switch off the cross-checking, it's all good now.
Cheers
|
|
|
|
|
It's probably a known problem, so maybe someone could give me a hint before I start digging into the problem, trying to reinvent the wheel.
My client has no support for SegWit (yet).
When it parses new testnet blocks (ones that spend segwit outputs), it takes ages to process them...
Does anyone know what is going on?
|
|
|
|
Sorry, I just realized that they sent me a message on 13th of October, which I somehow missed. This is not your account. Therefore I can not help. While we would like to assist you with your inquiry, for the security and privacy of our users we can only work with the account holder directly. If you are the website owner, and account holder, please submit a new support request from the email address you used to register your Cloudflare account. Note that you can also open a ticket directly through the Cloudflare dashboard following the below steps.
1. Log in to your Cloudflare account and click on 'Support' in the top right corner, which will take you to our Help Center.
2. Click on your name in the top right corner, and in the drop down menu select 'My Requests'.
3. Scroll to the bottom of the 'My Requests' page and click 'Submit new request' to submit your ticket.
We apologize for any inconvenience these extra steps may cause, but appreciate your patience and understanding to ensure the security and privacy of all our customers (including yourself).
Best Regards,
Kirk D. Washington II - Cloudflare Support Engineer It is possible though, that they fixed anyway. Please anyone report, if you had error 523 trying to load https://en.bitcoin.it/ Is it fixed now - or is it still there? |
|
|
|
Update: In Austria it now works again.
Thanks. I submitted the traceroute's result to CF's support, but haven't heard from them ever since. I assume they have looked into it by now. |
|
|
|
Guys, I have moved recently and I don't experience this problem anymore from where I am now. Whoever is facing the issue, could you please capture a traceroute from your location to a cloudflare server and post it here? Like they say: a useful piece of information to give to CloudFlare's support team is a traceroute between your origin and one of CloudFlare's IP addresses (ideally one of the addresses that you usually see send requests to your site). I have a support ticket open at CF - if I get the info, I can push it forward. |
|
|
|
It seems to be cached. This seems to be implied by this comment in the signing stuff: Furthermore, it is guaranteed that identical signatures (including their
recoverability) will have identical representation, so they can be
memcmp'ed. More likely they're using deterministic signatures. https://bitcointalk.org/index.php?topic=727918.0I think it wasn't like this before. Perhaps it came with the sipa's secp256k1 lib. |
|
|
|
They answered: Thank you for contacting Cloudflare Support. I am sorry to hear that you are experiencing some difficulties here.
If you are seeing an Error 523, it means that there is an issue from the origin web server, as it's unreachable.
A common cause is that the DNS setting has changed. Sometimes, hosting providers update the origin IP information for their customers. If this is the case, you need to make sure the new origin IP address for your A record is reflected in your CloudFlare DNS Settings page. Once make the change in your CloudFlare DNS Settings page, wait up to 5 minutes for it to take effect.
Another common cause of 523 errors are internet routing issues between CloudFlare's systems and the origin (i.e. the web server where the site is hosted). This can be caused by issues with an internet provider between your origin and CloudFlare, or with the origin itself. If you are confident this isn't caused by your web hosts, a useful piece of information to give to CloudFlare's support team is a traceroute between your origin and one of CloudFlare's IP addresses (ideally one of the addresses that you usually see send requests to your site). You can find instructions on running a traceroute test here. That should help them to pinpoint the issue.
523 errors can also be caused by Railgun. If you are the customer of a Hosting Partner of CloudFlare and you are using their Railgun, you should contact them about this. If you are running your own Railgun, then you should contact CloudFlare's support team, providing the most recent syslog file from your Railgun server if that's possible. |
|
|
|
What would you think about decred.org from the developers of other golang bitcoin client ? Sorry, I don't have an opinion. I'm too much involved in my bitcoin stuff and have no time to look into alternative-crypto projects. I rarely even look in other bitcoin projects - mostly if they have something I might want for myself |
|
|
|
Here's an analogy that might help you understand the scale.
If you had 1000000000*60*60*24*365.25*100 carbon atoms packed together in a diamond, it would be a 0.000314 carat diamond. Take a 0.5 carat diamond and smash it into almost 2000 dust particles, and one of those dust particles is 1000000000*60*60*24*365.25*100 carbon atoms.
Now, if you had 2160 carbon atoms packed together in a diamond, it would have as much mass as the entire Earth. brilliant analogy |
|
|
|
Maybe you can try to contact cloudflare's support and see if they can help you out?
ok, done - now waiting... |
|
|
|
It's same here, in Greece.
Does anyone has the wiki working ATM?
Works without a glitch from western-europe... OK, thanks. So I guess nobody's going to fix it for us   |
|
|
|
|
It's same here, in Greece.
Does anyone has the wiki working ATM?
|
|
|
|
|
Show Posts
