b) Miners who mine with this code will require a fee >= 0.001 to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005 to relay TX's with
outputs <= COIN_DUST
Why not make these be b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005COIN_DUST/2 to relay TX's with
outputs <= COIN_DUST
? I have an even better proposition const COIN_DUST_FEE_MULTIPLIER = 0.5; b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005COIN_DUST * COIN_DUST_FEE_MULTIPLIER to relay TX's with outputs <= COIN_DUST |
|
|
|
There would be no way to enforce this. Exchanges can choose for themselves whether to be open or closed in the weekend or at other times.
How about community enforcement? Let me add some more emphasis so I am clear:     |
|
|
|
Fail is over 9000
Yep, fail meter is never wrong.  |
|
|
|
Are you sure this calculations are correct ? Also, does "other currencies" contain gold & silver bullions + diamonds ? Even if these calculations are correct then we have roughly 5,000,000,000,000,000 (5 quadrillions in US scale or 5 trillions in normal scale) units of dollars in circulation. If you add 2 more zeros for penny, then we have =5,000,000,000,000,000,00 units of dollars vs 21,000,000,000,000,000 units of bitcoin So no, as you can see - it isn't enough. At least 2 zeros (or better 3) are missing from this picture. |
|
|
|
hi, i want to know if there is a tutorial or someones who can explain how to fork bitcoin. Im willing to pay for the labor of forking bitcoin.
thnaks.
If you are asking for a tutorial for making a fork.... then you probably shouldn't make a fork in the first place. Heh. Forking is easy. Just change anything important, and you will no longer be compatible with bitcoin.
What you described is not really simple forking. It's creating an alternative currency, additionally to forking. Forking is what I did, but i did not create new currency with that. |
|
|
|
It's really unlikely that bitcoin will replace all world currencies in 20-30 years.
Of course it is very unlikely, but that is not the point. The UNIX engineers of 1970's also thought that it is really unlikely that anybody in 2013 will use their code & standards such as 32bit UNIX TIMESTAMPS limited to year 2038 and Ipv4 limited to roughly 4.000.000.000 addresses. This shows that humanity is not really very good at thinking ahead, especially when speed of changes is rising exponentially. So let's design ahead while you can, do not wait for the problem to show up (especially that now it is extremely easy to change something, and with time it will be more and more and more difficult, nearing impossible in few decades). |
|
|
|
I think you don't really grasp what 2^160 actually means... let alone 2^2048...
This +1. To the supports .... D&T rant mode engaged. 1) Bit strength alone is utterly meaningless. ECC was designed to use a smaller key size yet produce the equivelent security of larger key sizes used by RSA. 256 bit ECC has the equivelent security of 3072 bit RSA. The whole POINT of ECC was to reduce key sizes without reducing security. Increasing the size of the hash to larger than the ECC key is a good way to just waste space. It does absolutely nothing. 2) There aren't even any vetted ECC curves beyond 512 bit because it makes about as much sense as idiot LEET hackers speculating that if 2048 bit RSA is good then 4892374190289378952347589347528945 bit RSA must be even better. 3) 160 bits can't be brute forced. Period. To put it into perspective the entire bitcoin network has performed roughly 2^56 hashes and comparisons. If the Bitcoin network was one trillion times faster (note that is roughly a million times more computing power than the entire planet combined) it would take "only" 80 quadrillion years to have a 50% chance of brute forcing a single 160 bit hash. Most miners understand difficulty so brute forcing a 160 bit key is like a solving a block with a difficulty of 79,228,162,514,264,300,000,000,000,000 4) Larger key strengths are useful in the event an algorithm is partially compromised HOWEVER it is more important to use well known and vetted algorithms which are less likely to be compromised in the first place. Moving to Bobs Leet 2048 bit hash is of little utility if it is broken wide open providing about 20 bits of effective security vs no practical attacks on RIPEMD-160 or SHA-256. 5) Public addresses are the product of a double SHA-256 hash AND RIPEMD-160 hash of the public key. This provides resistance to cryptographic attacks as it would require not just a flaw in one algorithm but a significant exploitable flaw in two completely unrelated and highly vetted hashing algorithms to have any useful applications. 6) Nothing is free. Larger keys, larger public addresses (hashes), and more decimal precision takes up space. The idiotic idea of going to a 2048 hash would increase the size of all transactions by a factor of nearly 13. To put it into perspective if the network currently used that the blockchain would be nearly 40GB and growing by 5GB or so a month. All those scalability limits (bandwidth for a node, computing power to verify tx, annual storage growth requirements, time to bootstrap a new node) would all be increased by a factor of 13. Your arguments are valid. Actually I already realized validness of these arguments before, however I am a hardcore crypto freak and i like if my cryptography is blazingly, incredibly strong. I actually use 4096-bit VPN keys to communicate between some of my servers even though i know very well that 2048 is more than enough. So, now that we have determined that more cryptography is not necessary, what do you think about adding more decimal places ? This is not an unrealistic future problem. If in 30-40 years Bitcoin becomes world's #1 currency, then 8 decimal places will not be enough. Why not simply add them now while it is extremely easy instead waiting for problems in the future ? When Bitcoin becomes widespread, it will be much more difficult to change anything than it was to change from Ipv4 to Ipv6 protocol (because of all the mining hardware). Bitcoin may never scale to a level where such precision is useful. Say we increase it to 16 digits. Why not 48? or 96? or 2000? Now you likely are thinking 2000 digits, now that is stupid. 9+ is really no different.
However, that argument is invalid. Bitcoin "may never scale" they said. But it also MAY scale - what's then ? This is a foolish "let's wait for the problem appear, before dealing with it" kind of thinking. Say we increase it to 16 digits. Why not 48? or 96? or 2000? Now you likely are thinking 2000 digits, now that is stupid. 9+ is really no different.
Really ? That's a simple problem. We can calculate the minimum unit from following algorithm: # [Total value] = all Dollars in circulation + Euros in circulation + Yens in circulation + CNY in circulation + all the other currencies
# Convert [Total value] to amount of smallest units/fractions of the earth's cheapest currency (*excluding* internet currencies and currencies of countries with hyperinflation)
# Add one or 2 zeros.
There you have it. The humanity will probably never require more units of Bitcoin than that, even if Bitcoin becomes #1 World currency and everybody on the world starts using Bitcoin instead of other currencies. Currently, total amount of the smallest units of Bitcoin is 2,100,000,000,000,000 which is just over 2 thousands of trillions (USA scale). Is it enough according to the equation above ? I highly doubt so. |
|
|
|
Math is scalable.
HDD space and bandwidth isn't necessarily.
Hardware & human lazyness combined with reluctance to change scales even worse. As i pointed out, it will be at least 1000 times as difficult (& costly) to add decimal places or increase cryptographic keys lengths in the future once Bitcoin becomes widespread. So why not do it now instead of waiting for it to become another "case" like Ipv4->Ipv6 transition. |
|
|
|
- Longer private/public keys = more possible addresses, better protection against money loss due to the identical address generated by 2 people
There might be something to other points, but this is not a real thing. Yeah, i know that if right now everybody on earth would generate 10 random addresses a second for 10 years, then the probability of hitting the same address by 2 people would be like 1 to 66,205,589,862,420,404,716,771,980,897 but still... using longer addresses would be even safer !!  |
|
|
|
Disclaimer: This is a general attitude and not based on defeating ECDSA with RIPEMD
It's sad and all too common to see reactive positions on problems or tweaks when it's relatively easier to fix them sooner than later. Particularly when system adoption is a few thousand vs. possibly millions in the future.
+ 1000 Yeah, I really hate the "Let's wait until it becomes a problem" attitude. A good example of major change in a widely adopted, but loosely organized system is IPv4/IPv6. This transition has been dragging out for many years and has resulted in all sorts of intermediate protocols in attempt to overcome the sheer difficulty of wholesale replacement.
Exactly what I am saying. -------- Let me sum up the benefits: - Longer private/public keys = more possible addresses, better protection against money loss due to the identical address generated by 2 people - Longer private/public keys = better security when a flaw in one of the fundamental algorithms is discovered - More decimal places = after bitcoin becomes widespread, it will be suitable for transferring/storing smaller amounts of money - It is 1000 X easier to fix the issues right now instead of later |
|
|
|
Also because a Bitcoin address is a combination of ECDSA with RIPEMD then provided that you don't re-use addresses (so yes vanitygen addresses are not the best and I am well aware of my own sig) then even if ECDSA is broken by some future QC machine (which I seriously doubt will exist for a very long time from all that I've read so far about this technology) you will not lose your bitcoins (as *both* ECDSA and RIPEMD would have to be broken for this to occur).
This discussion is also about adding more decimal places *before it becomes a problem* rather after it becomes a problem some 30-40 years in the future. |
|
|
|
|
I forgot to add, than we can add just the networking & protocol support for 2^512 & 4-6 more decimal places and wait 2 or 4 years with the actual implementation, so everybody will have enough time to prepare.
|
|
|
|
- The same issue with Y2K problem.
The conclusion ? Everybody always thinks that their system will be replaced by something new & better in the future, but it often does not happen, hence the problems we have today.
Know why Y2K happened and went without anything happening? Because the systems were replaced by something new & better before then. Deal with issues when the need arises. There's way more important stuff to deal with first. obviously the Y2K problem got solved far more expensively than if they had fixed it in the first place by thinking long term, but … if you always care about every eventuality beforehand you might decide to not even get started. It's about priorities and not about doing the right thing now for all eternity. Yep, exactly. "Let's fix it when it becomes a problem" is IMHO a very shortsighted & foolish way of thinking. Especially when fixing it now is extremely simple and fixing it 10 years into the future will be orders of magnitude more difficult because of the reasons i wrote earlier. Of course, 2^2048 is obviously too much, but why not 2^384 or 2^512 ? I don't see anything wrong with that. |
|
|
|
^ i disagree.
i think in the future, most bitcoin-related transactions will not occur on the actual blockchain and hence won't be restricted to 8 decimals anyway.
the 8 decimals will only restrict the balancing of accounts between large institutions that actually use real tx's.
This is one of possible scenarios. However nobody can exactly predict the future and it won't hurt to prepare for another probable scenarios instead of just doing nothing ? However, the UNIX sysadmins of 1970s also never thought that their code will be used to this day and by so many people and - This is the reason we need to do Ipv4 to Ipv6 transition today. - For the same reason, the UNIX TIMESTAMP does not support dates beyond 2038 (was it 2038 ? or 2035 ? I don't remember exactly), which already causes problems in software today. - The same issue with Y2K problem. The conclusion ? Everybody always thinks that their system will be replaced by something new & better in the future, but it often does not happen, hence the problems we have today. |
|
|
|
|
I support this. Additionally I propose we add more decimal places (4 zeros or more) simultaneously. Logical reasons:
1. In the future, there may be multiple "mainstream clients", so coordinating between different development teams may be more difficult by few orders of magnitude
1a. If that happens, there will also be multiple code bases and changing all of them to comply with new standards will be very difficult
1b. Because of that, there will be also much much much more testing required, and many many more possible bugs will be produced because of the transition
2. In the future, Bitcoin may be heavily used by many powerful financial institutions and each of them will have its own agenda. They may or may not like the enlargement of decimal places & private/public keys for reasons not yet known currently.
2a. Large institutions (including financial, governments) have large inertia. It will be difficult for them to make transition to any new standards.
3. In the future, Bitcoin will probably be implemented in many embedded devices (such as ATMs, smart wallets, smart credit cards, "smart bitcoin safes") etc. So it will be even more difficult to implement it
4. In the future, it will require much more convincing people to switch to the "new, better Bitcoin with longer keys".
5. Just look what happened with Ipv4 -> Ipv6 transition. The same will happen with Bitcoin. It will be extremely difficult to make any changes once it is widespread.
|
|
|
|
The right approach to handling load spikes on a forum like this would be full-page caching in the web layer
It is a good idea, however it will not be enough. There should also PHP-side cache based on Memcached to offload MySQL/MariaDB servers. I don't even use Varnish and still I can serve hundereds of requests per second on single server. You can get performance increase of thousand percent and more. Been there, done that. Check this out: $ mysqladmin status
Uptime: 3154789 Threads: 16 Questions: 3738552556 Slow queries: 112796 Opens: 27041477 Flush tables: 1 Open tables: 1482 Queries per second avg: 1185.040
This is a single Quad Core server, it contains MariaDB, NGINX, Apache and PHP - all on a single server. It serves total of ~1.400.000 views/day (when you count google/yahoo bots). And i still think i can squeeze out much more speed using NoSQL. Also, my MariaDB tables contain ~15GiB of data, with total of 65 million records. |
|
|
|
Why the hell is the forum unable to cope with the traffic given how much has been donated to upgrade the software? Seriously, the software upgrade seems like vapor-ware at this point.
the forum needs to be running on http://www.litespeedtech.com/ instead of apache which i have offered up a license 100% free for use on the forum (i'd even pay the support/updates contract) (for sale in this thread https://bitcointalk.org/index.php?topic=122271.0) Seriously ? Why not simply use NGINX with PHP-FPM instead (If not already using it) ? NGINX is already used by many large sites and is blazing fast - I don't think there will be much debate over it. PHP-FPM is slightly faster than SPAWN-FCGI or custom script dispatcher, but consumes much less memory (as all php processes share memory).+1  Also, moving from MySQL to MariaDB could be helpful. "Normal" MySQL is not really developed anymore, as Oracle does not give a duck about it - they only want your money by selling you closed source extensions. I have already moved my 2 servers with 50+ million views/month to MariaDB and I am serving ~35 million views with single quad-core server (but of course heavy caching is involved).  I use XtraDB instead of the standard InnoDB. I serve 40 req/s med and 100 req/s top on a single server. It heavily depends on the patter of the visits. MariaDB contains XtraDB (it replaces InnoDB "drop in", plus it is binary compatibile, or at least MariaDB devs claim so) |
|
|
|
Why the hell is the forum unable to cope with the traffic given how much has been donated to upgrade the software? Seriously, the software upgrade seems like vapor-ware at this point.
the forum needs to be running on http://www.litespeedtech.com/ instead of apache which i have offered up a license 100% free for use on the forum (i'd even pay the support/updates contract) (for sale in this thread https://bitcointalk.org/index.php?topic=122271.0) Seriously ? Why not simply use NGINX with PHP-FPM instead (If not already using it) ? NGINX is already used by many large sites and is blazing fast - I don't think there will be much debate over it. PHP-FPM is slightly faster than SPAWN-FCGI or custom script dispatcher, but consumes much less memory (as all php processes share memory).+1 Also, moving from MySQL to MariaDB could be helpful. "Normal" MySQL is not really developed anymore, as Oracle does not give a duck about it - they only want your money by selling you closed source extensions. I have already moved my 2 servers with 50+ million views/month to MariaDB and I am serving ~35 million views with single quad-core server (but of course heavy caching is involved). |
|
|
|
Why the hell is the forum unable to cope with the traffic given how much has been donated to upgrade the software? Seriously, the software upgrade seems like vapor-ware at this point.
the forum needs to be running on http://www.litespeedtech.com/ instead of apache which i have offered up a license 100% free for use on the forum (i'd even pay the support/updates contract) (for sale in this thread https://bitcointalk.org/index.php?topic=122271.0) Seriously ? Why not simply use NGINX with PHP-FPM instead (If not already using it) ? NGINX is already used by many large sites and is blazing fast - I don't think there will be much debate over it. PHP-FPM is slightly faster than SPAWN-FCGI or custom script dispatcher, but consumes much less memory (as all php processes share memory). |
|
|
|
|
And thus Bitcoin became the currency of the internet.
|
|
|
|
|
Show Posts
