 Show Posts
|
|
Pages: « 1 2 3 [4] 5 »
|
Risk vs reward. No offense to Hal, but 25% isn't a very big improvement, and signature verification is something that absolutely must work correctly. Get it wrong and people can lose a lot of money very quickly. Why risk it?
Yes, inprinciple I agree, 25% is not much (I only got 22%). But if Hal's secp256k1Verify code is integrated into pre-0.8.0 it could end up to be inserted in the next 0.8.0 release officially. This means, other people recognize this as an important improvement. And in the light that the probable bottle-neck is (or just has become) this ECDSA_verify heavily(!), I can understand their decision. To answer your question "Why risk it?": To not lose more and more potential new users because they are annoyed by the huge real-time necessary to verify the current block chain with the official bitcoin versions. It seems most people don't see this real danger -- this real-time behaviour might restrict (or even kill) bitcoin usage/spread seriously. :-( smtp |
|
|
|
Building works fine on my laptop, but I believe I hit the same problem when trying to build release binaries for Linux in gitian. It may require the package 'qt4-linguist-tools'.
You deduce from your environment to other people's environment.  Seriously, when calling "qmake" in the directory $HOME/tmp/bitcoins/bitcoin-0.7.1-linux/src I get no errors but the message Project MESSAGE: Building with UPNP support Project MESSAGE: Building with UPNP support Removed plural forms as the target language has less forms. If this sounds wrong, possibly the target language is not set or recognized. I don't know whether this should sound wrong or not, but obviously something has changed regarding "bitcoin-qt.pro" compared to the old release 0.7.1. smtp |
|
|
|
The batch verification thing does sound interesting. It's almost ideal for BitCoin in fact.
Since nearly 2 years has gone but no activity for this "batch verification"-algorithm has (seemingly) done/published, I like to ask: why? smtp |
|
|
|
I've uploaded a new set of builds of bitcoind/Bitcoin-Qt to my builds page. The new "turbo" build is based on current master on git, plus some more experimental patches (Hal Finney's optimized secp256k1 code, and parallel script verification). The source code for these can be found here (.tgz archive here). I just have downloaded the current source version (1869678 bytes), "tar -xf bitcoin-turbo.tar.gz" it and call in the new created directory bitcoin-turbo the "qmake" . But gets lots of error messages about being unable to find all these local language files: Project MESSAGE: Building with UPNP support Project MESSAGE: Building with UPNP support lrelease warning: Met no 'TRANSLATIONS' entry in project file '/home/achim/Downloads/bitcoin-turbo/bitcoin-qt.pro' RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_bg.qm' RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_ca_ES.qm' RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_cs.qm' .... RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_zh_CN.qm' RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_zh_TW.qm' So, what are the exact preconditions/dependencies for compiling this turbo-bitcoin source successfully? (Are there linux-binaries availible?). I want to make a speed measurement of blockchain verification with this bitcoin-turbo release compared to my own blockparser. Currently I'm able to make 939.88 script-verification/sec with my 2 GHz AMD Athlon(tm) 64 Processor 3200+ stepping 00 processor (a few years old) using gcc 4.4.5 with (my default) options -march=athlon64 -O2. Thus I wonder, a new, say 3 GHz cpu with 6 cores should even be able to acomplish 10000 script-verification / sec or more today ... not to mention optimized secp256k1 code. Appendum: "qmake -v" results in QMake version 2.01a Using Qt version 4.7.2 in /usr/lib64/qt4 smtp |
|
|
|
Using hashes for signatures, where you reveal a secret to spend an output that contained it hash, you give the world the ability to steal your coins as soon as you spend them. For example, any miner could change the transaction to send it them self by using your revealed secret. This is an inherent problem with symmetric cryptography. You need some secret that only you know to prove your identity.
I c, Thx. But to spend something I need NOT to prove my identity principially. The problem in the bitcoin-model are the miners, because only this special subcommunity can put my transactions (or what ever they want) into blocks. Thus I must trust them not to change my transaction or need another algorithm (signature) to check/prove that theses did not change my transaction. This I had forgoten. :-/ I always feel uncomfortable by relaying on these miners in this bitcoin-world - I mean, to be unable to write my wanted transactions by myself into the block chain. I have seen systems validate over 5000 tx/s (on a 6-core, hyperthreading machine with hal's optimized ECDSA code), so I think in the near future, we're good (at least until the block size limit would be lifted). Not every machine will be a full node, but if hardware to keep up and sync at least at over 1 block/s, is available to consumers, we probably don't have that much to worry about.
Fine, and what about the guys still have half the CPU-power (or less) than me? I did a bit preciser estimation: I needed 160 sec to read the block chain up to height 21500 (and get all data in place), but then needed 1031 sec (the wrongly 1191 sec was including the 160 secs) to read and verify the next 1283 blocks (which contain a total of 838243 OP_CHECKSIG). Which shows a speed of 813 tx/s (not 704 tx/s) (script-verifications) -- far more realistic/typical than your 6-core hyperthreading parallel machine, IMHO. BTW: I believe the most cpu-time consuming part of the signature-verification is the modulo-n arithmetic (with n a 256-bit number). smtp |
|
|
|
The bottlenecks are now the crappy block download mechanism (which sometimes stops for several minutes) and signature verification (which is needed in practice, and is several orders of magnitude slower than all the rest combined). The last point can only be critical, if CPU-usage tends to 100% not the waiting time of the bitcoin client. The only checking my blockparser doesn't do is the merkeltree-hash of each block (I was still too lazy to do the coding) and this OP_CHECKSIG (resp. OP_CHECKMULTISIG), but I had read and understood its detailed description on https://en.bitcoin.it/wiki/OP_CHECKSIG. Thus I can't judge how cpu-intensive this OP_CHECKSIG evaluation really is. Today, the first time my blockparser could verify the current block chain (until block height 216049) completely. (I removed a few bugs in the documentation at https://en.bitcoin.it/wiki/OP_CHECKSIG - but I did not implement the hashtype SIGHASH_SINGLE and therefore did not check its documentation (because it is currently not used in the main block chain.) Thus I can now judge your "several orders of magnitude slower". Indeed, roughly 99% of the CPU time is used for evaluation of all these OP_CHECKSIG (about 8 hours real time on my 2 GHz Athlon64-PC) when checking the total block chain. My (first) guess: Either we need a much faster implementation of the openssl function ECDSA_verify or abandon this OPCHECK_SIG. E.g. a hash computation (and its verification) only should be of equal security, but it is much faster than verifying a signature. Already some bitcoin-transactions in the block chain have used a "OP_HASH160 <14> OP_EQUAL"-script as txout-script. smtp |
|
|
|
What you seem to be missing from my point is the mathematical beauty of the "abstract time measured by the proof of work". The rules of Bitcoin have a beautiful property of statistical resistance to all kinds of cheating unless done by the 50%-or-more majority. No minority group can subvert this mechanism by coordinated cheating with timestamps, neither by moving block time forward nor backward.
This abstract, mathematical model I appreciate greatly, indeed since more than 1.5 years I got knowledge of it - I may add I don't know all details of the model, but its projected aim looks convincing to me. But to use it in reality efficiently, you need to define (better) time(-distances) in it. Time rules reality -- and to give a more known economic proverb for our case: Time is money!  smtp |
|
|
|
Nonsense, many common payment mechanisms have horizons of _months_ before transactions become irreversible. Moreover, you can't simply reduce the time as though it were a free parameter. As the time between blocks falls below the time it takes nodes to globally communicate and validate new blocks the time until convergence tends to infinity. 10 minutes may have been more conservative than needed but it cannot be made arbitrarily low in a universe with a finite speed of light.
Whom want you to impress with such a beginner attitude stated in your last sentence? Almost all transaction in real life are much quicker than 10 minutes. Go to a train stop and image in 50 year use an electronic card when go into the train to pay. Or even today if you are in the shop and want to pay with your master-card. These TYPICAL transactions should be last say 10-15 sec AT VERY MOST. Therefore the time limit which is to be aimed at should be say 1 sec -- of course we have some decades time to reach it. If BTC-money payment only can go down to say 1 min, far more than 99 % of transactions in real-world usage will need another currency which is then of course of much higher importance, and then I see no sense to support BTC anymore myself -- it is (will stay) only a specialized currency in a small corner in the real world. Thus time needs to be like a free parameter (in the model) which over the years has to be decreased -- as I already indicated in relation to net-propagation speed and size/frequency of total usage of BTC. Sorry, but some people are obviously unable to have/imagine a great future-plan and already lay barriers in the beginning which prevent the possibility to have only a real chance to get one good world-wide paying system/currency. It seems to be that many people' error here in the community is: you need external time service (for closer timings / global faster transactions) -- only because in standard PC built-in time-hardware has too low precision. smtp |
|
|
|
But he designed something intellectually consistent: abstract block-time, completely self-contained and discoverable by looking only inside the blockchain and only backward.
Well, a model/design which have dozends, probably hundreds of arbitrary chosen parameters as closer you look turns out, I should praise/appriciate? You are joking. :-/ I never believe Satoshi had aimed at / wanted such a chaos/complexity which now is realized. Please post something that shows that you understand how time-invariance of blockchain verification contributed to the security of the Bitcoin protocol.
You miss the point. I claim a practical "same security level" can be achieved without allowing 2h - wrong time-stamps, believing in say 30 sec inprecisions. ... as everyone would become dependant on centralized sources of time.
Nonsense. It seems you have no knowledge how cheap/expensive and precise simple good quartz-clocks can be today. BTW: IF bitcoin should ever get more in the wide-spread scale of a common real-world currency this average 10 minutes time-distance must be very significantly lowered and probably other practical timings narrowed. Else many typical purposes can not use it and bitcoin will remain an unimportant/small corner for most people - net propagation time will decrease with the years. One day, you will pay with your master-card and could this be in BTCs or are BTCs forgoten because their transactions would have had to be waited for many minutes to be confirmed? smtp |
|
|
|
One of them is that some goverment (probably USA) will subvert all observable time sources (NTP, GPS, etc.) yet the Internet will continue to operate. This is completely ridiculous, as vast majority of the modern digital communication is synchronous and relying on the precise clocks that are satellite-synchronised. Just check out the post above by retep; or earlier posts by gmaxwell or Hal. I find this level of misunderstanding of modern communication technology fairly prevalent, just check out this recent thread. https://bitcointalk.org/index.php?topic=133445.0 I gave it a quick read, to do you a favor. The real threat is not that a goverment would manipulate (satellite/ntp) timing to hinder/destroy bitcoin-network or any other technology, but simply changes laws and activate layers (and use police and justice) to restrict its usage severly or totally! This happened already again and again in the past. smtp |
|
|
|
The other side of this argument proposes two algorithms: one real-time (for "current" blocks) and one past-time (for "historical" blocks). I have yet to see anyone who proposed a single contiguous algorithm which will reject the same blocks both when seeing them on the p2p net and when verifying the stored blockchain. Can you write a proof that your pure function "valid(block,blockchain,t)" is both independent of the "t" parameter and somehow better than the old "valid(block,blockchain)" function? And for what definitions of "better"?
It is not my job to design something what could be perhaps accepted and get preciser timing in the community. But here is a very simple variation: It was chosen: 2 hours of time-difference, because a HW-clock has a typical 100ppm inprecisiosn and a miner should be able to run for 1 year without time-correction with standard clock! This was a mistake to allow! You also could have set the arbitrary limit to 1 month --> 120 minutes max go down to 12 mins max difference. But I would like to have a measurement which is much less than this 10 minutes of average block-time distance! Thus I wanted 1/2 min - a time less than the typical net propagation time, I believe. Then I also may have a good chance to see first effects of net-propagation which else are covered totally by time-variations of local wrong miner-time. Through away (time-)information is trivial, but getting lost information back often impossible. Just springs to my mind: would be interesting in regard to creation times of orphan blocks. smtp |
|
|
|
Your average computer has a cheap internal clock with roughly 100ppm overall accuracy. Thus in 1 year you can expect a maximum of about 0.9 hours of drift. Roughly speaking the existing timestamp protocol rules mean that the worst case scenario of an unattended mining computer without ntp, left drifting for a year and suffering a botched daylight savings update still has a 50:50 chance of producing valid blocks. That's a good thing! Your typical miner who buys special grafic cards for mining or an much more specialized hardware and let run his computer unchecked for months(!) should also be in the duty to buy/or program a better hardware clock for his machine - we really don't need theses miners, there are far enough who are eager to mine due to block-income and will adjust their clocks much more ofter if necessary. You also can't force NOT to use ntp! :-) Anyway, thanks very much to try to reason in detail the (historical) background which led to the current situation. I would like to interprete the time-stamp as the time when the block got known to the network -- and network propagation is in the order of a few minutes at most. I just checked back in blockchain: 207498 & 207497 (last november) - 65 min difference .. and there are still worse. There is no excuse for this bad design, IMHO. :-( Appendum: network propagation time is not the time you reach 100% of the nodes (this can last arbitrary long) but a certain fixed high amount e.g. 90%. BTW: My feeling is: possible (trying) mining should be as wide-spread as bitcoin-transfer in the future - else there will be a splitting in the power of the bitcoin-usage: miners (a very small subcommunity can decide which transactions are delayed or even never included in blocks) and (silly as usual) customers - I have a very bad feeling by these current "relaying" politicis if they continue for long. If there are 10^6, say, firefox users trying mining (during there usual surfing) with their CPU idle time than they have about the same chance to 1 miner with his ASIC-hardware chips of 10^6-times mining power. smtp |
|
|
|
Obviously we understand "sane" much different. And a time stamp, say < 30 sec off the true time should be very easily available for every miner PC-user.
If I remember correctly the variation is up to 15 min, but everybody can see this in the block chain himself. You can sometimes notice blocks form the future or blocks which are younger than their predecessor if you looking for new dropping in blocks.
This nonsense I don't call sane.
This reduced-sanity mode is there to allow a part-time on-line/part-time off-line operation. You'll need to come up with a better sanity checking that doesn't require full-time on-line operation and doesn't create orphaned sub-chains when coming up online after a downtime. Hmm .. even my watch has a much better offline-time precision - it is a cheap quartz-watch (no radio-watch). Sounds more like a design-bug or probable pure design quality which noone inside the community really cares at this special point. But to everybody outside, who get knowledge of this fact, might/could indicate/estimate low quality of the whole bitcoin-project. What and how miners get the true time into their then mined block is their problem like all other header values to be (checkable) correct. We must not be forced to accept such huge time inprecisions - ridiculous, IMHO. smtp |
|
|
|
....its not quite canonizing hard enough to only return 3, even if all there were were standard transactions.
Sorry, I was really unable to guess what you could have meant with this. But I decided that it no longer matters. Is there undocumented enforcement code in bitcoind? I can't figure out what even prompted you to ask that question. Your statement from yesterday I strongly recommend using testnet as the standard transaction behavior is not enforced there
prompted this question. BTW: Miners should be forced to put not obviously wrong time stamps in the new found block-headers, IMHO -- clients could simply not accept these blocks as valid. There is a protocol rule that limits the timestamps to fairly sane values. Obviously we understand "sane" much different. And a time stamp, say < 30 sec off the true time should be very easily available for every miner PC-user. If I remember correctly the variation is up to 15 min, but everybody can see this in the block chain himself. You can sometimes notice blocks form the future or blocks which are younger than their predecessor if you looking for new dropping in blocks. This nonsense I don't call sane. Look at recent blocks 214091 & 214092 and this is not a very extrem example. :-( BTW: For my original question, I think either I will have to help myself (writing own code - the first guy replying in this thread pointed me to these raw transaction API since 0.7 I did not knew) or stop having interest in for a while - I got tired here by your kind of "helpful" answering / commenting - this what I can check easily is often wrong, looks more to me that you are talking either without knowing the facts or don't care them, or don't care of correct/precise wording. Excuse my frankness. Regards, smpt |
|
|
|
Wrong? I did not state anything about this. I ask you why you considered cash only, or better what you called cash? It looks more you don't know what I talk/think about. And thus set money = cash. Regards smtp |
|
|
|
Bitcoin is cash not liabilities. The magnitude of cash floating around is much less than you calculate.
Image to go to a business bank in 50 years and asking for a credit. The bank offers you say 10 BTC. Will you ask: do I get this as cash? :-) Or if they offer you a 10 MBTC credit -- you are a well-known big-business man and you know that there (will) exists only 21 MBTC world-wide and it is almost the only used currency of importance -- what will you think then? smtp |
|
|
|
A serious and more non-future aimed thought would e.g. result in: start with say 2^16/1000 BTC half this every 210000 (or what ever fixed number) of blocks -- better choose the time interval 4 years and a certain distant of 10 mins for a new block, do this for 16*4 = 64 years, then we are at 1 mBTC and then hold this constant for ever! So you have a small linear growth in BTC total. Then we need no (new/very artifically and arbitrary changable rules for) transaction-fees! But we should retalk this topic in nearly 64-4 years! smtp |
|
|
|
What would happen when the subsidy was 1 BTC? Half of that is 0.5 BTC and further dividing that by 2 doesn't lead to ... 2 satoshi, 1 satoshi, 0. For that to happen, the subsidy would need to start at 2^n/1e8 BTC, which at n=32 would be 42.94967296 BTC, which is as nerdy as ugly.
The ugly thing is either 10 is no power of 2 or humans are not comfortable to think intuitively in powers of 2! ;-) smtp |
|
|
|
My two cents:
Currently the US-government has liabilities of a bit more than 15*10^12 $, say roughly 10^13 $.
Taken all of the other liabilities world wide, I guess their sum is limited by $ 10^14.
Moreover I believe all sums of every money availible (converted to US-$ units) is < 10^15 $ at every past point of time.
So if you like to be precise on the level of 0.01 US-cent, you need an integer range up to 10^19.
Hmm ... 2^64 = 1.84...*10^9. Wow, critical close if everybody would use BTC for his business! ;-)
smtp
Bitcoin is cash not liabilities. The magnitude of cash floating around is much less than you calculate. ? What do you call cash? I tried to estimate official existing nominal money amount. And liabilities should be (far) less than existing money world-wide! smtp |
|
|
|
the only thing "easy" to do with custom scripts is to create unspendable outputs and burn coins.
This just spring to my mind -- IF I create unspendable (or even spendable!) outputs and burn coins in the former case THEN a miner must have been cooperative as I expected and everything is fine. I also could send you my coins in contrast to burn them, the later lose would be lesser to me. BTW: Miners should be forced to put not obviously wrong time stamps in the new found block-headers, IMHO -- clients could simply not accept these blocks as valid. smtp |
|
|
|
|
