|
This has been known forever. It's not a problem: the block chain stores whatever data and charges the same fee per kB.
|
|
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 At the request of Sirius, who owns bitcoin.org and the server this forum is hosted on, I have moved forum.bitcoin.org to bitcointalk.org. This is the final result of a long email discussion among many developers, exchange operators, etc. I have always been opposed to the move, but Sirius wanted to act according to consensus. The forum was the only thing on bitcoin.org except for a few static pages, so I don't feel like we've lost too much by separating from it. All of the old forum links should still be working correctly except www.bitcoin.org links, which are out of my control. Additionally, I fixed some other URL-related issues. If you see any problems, contact me. Because the old wiki is hosted on this server, its new location is http://bitcointalk.org/wiki . -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAk42UFoACgkQxlVWk9q1kedZ8gEAqofd0TbShWadSewKV3SJWxZM VeJ8reeLjNm9RAdKggUA/01ifnMVoA2k6xLIjbBsfsgQsSaQk4dwEmVZv9f0fqsj =MVk5 -----END PGP SIGNATURE----- |
|
|
|
|
I read your reports, but the service hasn't been proven to be a scam, so I will not delete non-spam links to it.
|
|
|
|
|
This section is obsolete. Please move your topics from here to "goods", "services", "gambling", "currency exchange", or to the top-level "marketplace" section if none of those sections fit. The link to move your topics is near the bottom of the topic page.
|
|
|
|
|
This section is obsolete. Please move your topics from here to "goods", "services", "gambling", "currency exchange", or to the top-level "marketplace" section if none of those sections fit. The link to move your topics is near the bottom of the topic page.
|
|
|
|
Ну и че за нах? модераторов не хватает что ли, что за ебанько с ограничениями??
Пожалуйста, свяжитесь с Русской модератор " lzsaver" если у вас есть какие-либо вопросы новичка ограничений в русской секции. |
|
|
|
|
Cookies aren't marked as secure, either, so just visiting forum.bitcoin.org once with HTTP is enough to allow someone to hijack your account. I use NoScript to force HTTPS here.
|
|
|
|
Theymos, have you considered upgrading to 2.0? It was released over a month ago. I don't know if the they support such a feature in the new one but they have a lot of nice improvements added and over 2 years in RC's (even longer in betas) it seems pretty exciting for them to have a final 2.0 out.
It would probably be a big project. I'd want to keep the same forum style that we have now, and several of the modifications and custom changes that have been added would break. Can there at least be put a message shown when sending a pm, you have N pms left for this hour? I would if someone would contribute that code. Though if you're going to contribute code, you might as well implement membergroup-based limits. |
|
|
|
Also "SSL is slow" is a myth on modern hardware. Please stop propagating it for the sake of internet security. The crypto is not exceptionally slow, but the additional packets are. A full TLS handshake requires at least four additional packets. Also, some browsers will delay the connection until they've performed an OCSP check on the certificate, which can alone take up to a half second. All of this can add up to seconds of additional delay. I performed a simple test on http://blockexplorer.com/q/getblockcount . The HTTP version took 0.24 seconds, while the HTTPS version took 1.00 second. (This is due mostly to the handshake: additional requests would take almost the same time.) |
|
|
|
|
I'm eager to lend to trusted people, though I don't patrol the areas of the forum where these offers are posted. Someone needs to make a site for this.
|
|
|
|
I don't think it needs to be the default, though it should be supported if it isn't already. The URL request is not encrypted over HTTPs if my memory serves me correctly.
Wrong. |
|
|
|
|
I would increase it for established members if SMF supported that. A relatively small number like 10 is necessary to prevent mass spam, though 10 is still too high for newbies.
|
|
|
|
You can't send bitcoins without having detailed info about the transactions that sent them to you. The network works with transactions, not address balances. When you move BTC, you don't say, "I have access to this account, so check my balance and let me send the appropriate amount of BTC." You say, "I can prove that I received this transaction. I will redeem the BTC in it and disperse it in this way." The intermediate solution is to download only headers for blocks that you know have no transactions to you. It should take only a few minutes for Bitcoin to get set up on its first run after this change. But you still need to download all of the future full blocks or you will miss transactions to yourself. The long-term solution is to create some out-of-band way of discovering transactions to yourself. This could take the form of: - An additional P2P overlay network that allows anyone to search for transactions to certain addresses and retrieve them with high reliability. - Data sent directly from the sender to the recipient over the network or with a file. Additional extensions for retrieving Merkle branches would be necessary if both sender and recipient don't download full blocks. - Centralized services like my http://blockexplorer.com/q/mytransactions page can be used to get all of the required data without downloading any blocks. I find the sender-to-recipient method to be especially elegant. It makes intuitive sense that the sender of a transaction needs to give data to the recipient; some people are surprised that the current network doesn't require this. Merkle branches are only a few extra kB of data on top of the block headers, and they can be safely provided by centralized sources because they can't be falsified. |
|
|
|
I HAVE to ask for any explanation about that
I mean, either devs want any address version is ok for any network (and address versions become useless) or they want exactly one address version par network
Why accepting all lower ones but not higher ones?
The address checking code assumes that any version lower than the latest version is handled elsewhere in the code. Future versions could not possibly be handled. Example: If we move to SHA-256 hashes instead of RIPEMD-160 hashes, the address version will change to 1. Addresses with version 0 will still be valid, though: they will just be handled with the old code instead of the new code, or maybe trying to use them will trigger an informative error. Testnet doesn't include the cases for old versions that the checking code expected. |
|
|
|
What about these posts which consist of nothing but "+1", or "-1"?
I consider these posts to be off-topic because they have no point, but they don't cause much damage, so I usually don't delete them unless the poster posts useless replies a lot or the useless replies are reported. Other moderators might be more or less strict about this. And are we allowed to post "bump" with no furthur comment?
Bumping is necessary, so I ignore these. Do not bump more than once a day or many times in a row, though. |
|
|
|
So i can assume that truecrypt does not have any functionality built in to import a file with random data.
I'm pretty sure there is no such function. |
|
|
|
|
It's always been a part of my personal moderation policy, though I've only mentioned it before in a few replies.
|
|
|
|
|
Currently discussion/announcements/complaints about bitcoin-accepting sites is supposed to be in the top-level "marketplace" section, but I see a lot of this posted in "Bitcoin discussion" (where it certainly should not be). Should there be a new section for BTC-accepting sites, or is the current system OK?
|
|
|
|
|
TrueCrypt uses the system's random number generation facility, so on Linux you can just write to /dev/random.
|
|
|
|
|
Show Posts
