Pages:
Author

Topic: bitcoin/application/user-program supporting own scripts available? (Read 2883 times)

staff
Activity: 4284
Merit: 8808
He removed much more, new, helpful information, with the only given reason I may/could have removed some hidden details
You removed important information as I _specifically_ described here, and I didn't see anything important added. By commenting here shortly after I made sure that you wouldn't miss the change. You made _103_ consecutive overlapping commits to the the script page but change very little besides removing information with the result of the page being less complete and accurate.  Improving it is good, but not at the expense of accuracy.

One of the edits you've made on the wiki was so deeply incorrect— editing in direct opposition to the clear meaning of the pages— that I wondered if you were being intentionally wrong.   Your interest in Bitcoin is certainly welcome, but your ignorance of your ignorance and your disrespect towards others is unlikely to result in useful cooperation.

I do not oppose you continuing to participate here and on the Bitcoin wiki— but I think you will find more satisfaction if you participate with a softer hand.
member
Activity: 70
Merit: 10
I thought I'd alert those who have responded to this thread that he has also made over 100 edits to the script Wiki (along with other pages), so the community has a chance to review his changes.
Good catch. I've reverted— as in a quick review removed a bunch of useful information (e.g. removing the sizes of the returned types).

Chinese you say? Basted on the attitude, cluelessness, and wiki editing volume I would have guessed it was atlas.

Surprisingly I read this by chance, when wanting to improve a bit the URL https://en.bitcoin.it/wiki/Script .
Your change,
(cur | prev) 2013-01-13T01:52:33‎ Gmaxwell (Talk | contribs)‎ . . (16,312 bytes) (-34,010)‎ . . (Blind reversions of edits by SMTP, see this thread: https://bitcointalksearch.org/topic/m.1449369) (undo)
would be judged simply as vandalism on en.wikipedia.org, gmaxwell!

He removed much more, new, helpful information, with the only given reason I may/could have removed some hidden details (which I was not aware because I did not need them when writing an interpreter for this script-language!)? -- too bad for you. :-(  I personally suspect you have had private/emotional reasons to have acted so. I believe this bitcointalk-community is not worth my support anymore - too many guys who can't think analytically precise and rational reasoned is my feeling since being inside.
I make my decision to depart here only on gmaxwell's behaviour on https://en.bitcoin.it/w/index.php?title=Script&action=history, yes. A bit unfair probably,
but I judge my leisure time to be as too worthy to waste it in an edit-war with unable editor/author/lector, who is obviously dislike to keep objectively or improve articles like me!

BTW: It seems to me, that Gmaxwell is more clueless of what the op_codes precisely do than me who wrote a much preciser and more complete explanation (even with historical references) of the op_codes in the wiki-page after studying the bitcoin-source-script.cpp in detail - sorry, to call you publicly the bad guy with these lines. :-/

Fare well,
smtp
staff
Activity: 4284
Merit: 8808
I thought I'd alert those who have responded to this thread that he has also made over 100 edits to the script Wiki (along with other pages), so the community has a chance to review his changes.
Good catch. I've reverted— as in a quick review removed a bunch of useful information (e.g. removing the sizes of the returned types).

Chinese you say? Basted on the attitude, cluelessness, and wiki editing volume I would have guessed it was atlas.


legendary
Activity: 1512
Merit: 1036
Who's this "smtp"? It took one week from asking "what is this 'Satoshi code'" and not knowing about GPU mining, to bashing Bitcoin design and confusing core developers with noobs, while going right into the scripting language of Bitcoin for no reason related to transferring currency. Kind of like how Mohamed Atta didn't care about learning to land planes...

I'm going to guess Chinese from the style of ESL writing.

I thought I'd alert those who have responded to this thread that he has also made over 100 edits to the script Wiki (along with other pages), so the community has a chance to review his changes.

https://en.bitcoin.it/w/index.php?title=Script&diff=34921&oldid=34415

donator
Activity: 1218
Merit: 1079
Gerald Davis
Quote
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.

Bitcoin transactions are processed in a few seconds just like credit cards.  You will not the keyword above was irreversible.  It takes up to 180 days before CC transactions are irreversible.  On that scale 10-60 minutes doesn't seem excessively long.  It is certainly possible to accept 0-confirm transactions.  For physical world, and low value transactions that is likely all that is necessary.

Also remember that the entire network needs to synchronize.  That means propogation delays as well as verification delays need to be considered.  Due to the nature of Bitcoin (verify -> relay -> verify -> relay -> verify -> relay ... etc) it may require multiple "hops" before all nodes have access to the same block.   As gmaxwell pointed out 10 minutes is likely somewhat conservative one can certainly go lower but there is a cost and risk with going too low.   Anything below 1 minute is likely not viable without excessively high rate of blockchain forks and orphaned blocks.  

Lets compare some transaction times for settlement and funds availability

bitcoin 0confirm - ~ 1 sec
bitcoin 1confirm - ~10 minutes (varies 6 to 30 min within 1 SD)
bitcoin 6confirm -  ~1 hour

ACH (including "billpay") - 72 to 120 hours
Bank Wire (domestic) - 4 to 12 hours
Bank Wire (international) - 24 to 72 hours
Western Union - 15 minutes (unless delayed due to fraud prevention)
CC (inducing CC based systems) unconfirmed - ~1 to 15 sec
CC (inducing CC based systems) confirmed - 2880 to 4320 hours

Costs:
Bitcoin < $0.01 per tx
ACH ~$0.10 to $0.35 per tx
Bank Wire ~$10.00 to $35 per tx
Western Union ~7% to 10% of gross settlement
Credit Cards ~2% to 3% of gross settlement
Debit Cards ~1.5% of gross settlement

Bitcoins unconfirmed and confirmed settlement times are as good or better than other payment networks and at a fraction of the cost.



Still it seems you aren't really interested in learning or understanding so ....  Yup bitcoin sucks and everything about it was chosen to annoy you.  You likely should click logout and ignore it for another decade or two.
member
Activity: 70
Merit: 10
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! Wink

smtp
member
Activity: 70
Merit: 10
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
staff
Activity: 4284
Merit: 8808
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?

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.

It seems to me that like many of the more aggressively opinionated newbies that show up you are both clueless about the bitcoin system and the requirements of payment systems, and are just going to waste the time of anyone who bothers reading your posts. **Plonk**
legendary
Activity: 2128
Merit: 1073
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.
Quote
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.
OK, I think I now understand our miscommunication.

I don't disagree that the "same security level" can be achieved with better time accuracy. I agree on this point.

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.

So the single technical mechanism guards both honesty against double spending and against false timestamping. You may think that this is too complex; but I think it is mathematically minimal. In my opinion what you propose makes the Bitcoin more mathematically complex with unclear financial benefit.

Everyone here knows by heart that Satoshi considered transaction "confirmed" when it is 6 blocks deep in the blockchain.

Can you see the beauty of the fact that it takes 6 blocks to recognize that the time-on-the-blockchain moved forward? 6 blocks is measured statistically as a median-of-last-11-blocks. Anything less than 6-out-of-11 blocks wouldn't move the time forward! If it wasn't a median-of-11 but say average-of-11 then the time would move by an equivalent of increasing transaction confirmations by a fractional number.

6 may be an arbitrary number. 11 only looks arbitrary. It is actually dual to 6 by the duality of blocktime vs. blockheight. So if somebody proposes to change 6 without the corresponding change to 11, you now know that that person didn't really understand Bitcoin.

Yes, Satoshi could write this explicitly in his paper. But he probably set such a trap to allow himself to quickly grade the proposed changes to Bitcoin. So be aware of this when you making your own proposals.
member
Activity: 70
Merit: 10
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.

... 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
legendary
Activity: 1120
Merit: 1152
Not just 'not very important' but would be actually against the goals. You pointed out some of the risks, so I know you get it, but it deserves to be emphasized: Tight time requirements would provide no value to the Bitcoin currency but would in fact introduce substantial centeralization as everyone would become dependant on centralized sources of time in order to reliably meet the rules. Manipulation or disruption of these time sources would be devastating.

Agreed. A time window of 4 hours would have been quite reasonable too, although of course it's not worth it to change things now.

On a lark I did write up a sketch of a fanciful way of doing a decentralized time service using PoW chain consensus, you might find it amusing: https://people.xiph.org/~greg/decentralized-time.txt

Ah, yeah I saw that earlier. Fascinating, if unfortunately impractical!
legendary
Activity: 2128
Merit: 1073
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.
It's not your job? Dude, it wasn't Satoshi's job either. But he designed something intellectually consistent: abstract block-time, completely self-contained and discoverable by looking only inside the blockchain and only backward.

What you doing is just digging your own intellectual grave: flogging the hobby horse of parts-per-million clock accuracy and not showing any understanding of how abstract-but-cryptographically-secured time allowed Satoshi to make mathematical guarantees of security and convergence.

Please post something that shows that you understand how time-invariance of blockchain verification contributed to the security of the Bitcoin protocol.
legendary
Activity: 1120
Merit: 1152
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.

How many time sources is your computer synced to right now? Even of the people running NTP, the vast majority are connected to just a small handful of servers. You don't need to subvert all time sources, you just need to subvert a few for a few hours, because the average miner probably doesn't even check their mining computers daily. The system as it is can withstand a heck of a lot of neglect by miners, your ideas require active management and hence are fragile.

Again, what value to Bitcoin the financial network is there in having really accurate block timestamps anyway?

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"?

EDIT: on reflection, I think I misread what you were saying, in any case, digging through the below was quite informative for me.

The algorithm is more simple than you think. Every block of unknown validity, whether it's been given to us by a peer, or we're loading new blocks from disk with loadblock, first passes through the ProcessBlock() function. One of the first things ProcessBlock() does is it calls CheckBlock() which does the initial context-independent validity checks. CheckBlock() has only one timestamp-related check, and it's a really simple one:

Code:
// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
    return error("CheckBlock() : block timestamp too far in the future");

That just means that if a block has a timestamp more than two hours in the future we will always consider it invalid under any circumstance. Bitcoin doesn't use the "wall-clock" directly, instead the GetAdjustedTime() function, defined in util.cpp takes the average of all the times reported to us by the nodes we're connected to, and ourselves, and uses that as "time". However it won't let that median change what we consider as "now" by more than 70 minutes; replacing GetAdjustedTime() with just GetTime() is fine if you're clock is accurate. Note how this means that if you set your clock back in time Bitcoin will think perfectly valid blocks are invalid.

ProcessBlock() itself has only one time-related check:

Code:
// Extra checks to prevent "fill up memory by spamming with bogus blocks"
int64 deltaTime = pblock->GetBlockTime() - pcheckpoint->nTime;
if (deltaTime < 0)
{    
    if (pfrom)
        pfrom->Misbehaving(100);
    return error("ProcessBlock() : block with timestamp before last checkpoint");
}    

This code is only run if the block isn't part of what Bitcoin thinks is the best chain, and just makes sure that blocks before a checkpoint don't have a timestamp after the checkpoint. (this is why checkpoints have to be picked from blocks that don't have any blocks before in the chain with timestamps after them) Basically it's a sanity check to make sure that nodes can't DDoS you with fake blocks.

Once ProcessBlock has done its checks, it calls AcceptBlock() to do context-sensitive checks that depend on what previous blocks exist in the chain. It also has exactly one time-related validity check:

Code:
// Check timestamp against prev
if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
    return error("AcceptBlock() : block's timestamp is too early");

GetMedianTimePast() returns the median of the timestamps of the past 11 blocks, so basically this check is just ensuring that block timestamps are in fact going forward in time. Now there is also an implicit time-dependency in that the difficulty calculation, GetNextWorkRequired(), uses the block timestamps, but that's a second-order effect.

As you can see, all block validation is done without any reference to the current time at all, with the one exception that at any given moment we will consider any block invalid if it has a timestamp more than 2 hours into the future.

The reason why that one little rule leads to relatively accurate block timestamps is simply because miners want other miners to build on their blocks, so it makes sense to try to keep your timestamps accurate enough that the vast majority of miners will accept them as valid. Notably a 51% attacker who doesn't care about other miners can make the blockchain timestamps say whatever they want them too.

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.

Why do you need to do this?

FWIW I'm planning on setting up some servers that will automatically timestamp Bitcoin blocks as they come in against public RFC3161 timestamp servers - there are a variety of public ones run by certificate authorities and other trusted entities - and making the archives of those timestamps publicly available. That type of idea may be what you really want.
staff
Activity: 4284
Merit: 8808
Heck, I'm very slowly puttering around with a timestamping-via-bitcoin project myself, so believe me I'd love it if block timestamps were more accurate. But accurate block timestamps just aren't very important for Bitcoin's core purpose as a financial network.

Not just 'not very important' but would be actually against the goals. You pointed out some of the risks, so I know you get it, but it deserves to be emphasized: Tight time requirements would provide no value to the Bitcoin currency but would in fact introduce substantial centeralization as everyone would become dependant on centralized sources of time in order to reliably meet the rules. Manipulation or disruption of these time sources would be devastating.

On a lark I did write up a sketch of a fanciful way of doing a decentralized time service using PoW chain consensus, you might find it amusing: https://people.xiph.org/~greg/decentralized-time.txt

Quote from: smtp
But I would like to have a measurement which is much less than this 10 minutes of average block-time distance!
I want a pony.
member
Activity: 70
Merit: 10
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://bitcointalksearch.org/topic/what-would-happen-if-all-satelites-went-down-for-a-day-133445
I gave it a quick read, to do you a favor. Smiley 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
member
Activity: 70
Merit: 10
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
legendary
Activity: 2128
Merit: 1073
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.
I kinda agree that some design assumptions are ridiculous. But the design is a community-supported effort, and there are many people on the Internet who subscribe to very strange ideologies.

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://bitcointalksearch.org/topic/what-would-happen-if-all-satelites-went-down-for-a-day-133445

When you understand this bunker-level of paranoia you'll also understand the design choices for the Bitcoin time algorithm. It continues to operate in completely off-line mode underground or underwater, where you get to synchronize your blockchain by carrier-moles or carrier-dolphins. I can clearly admire the ideological consistency: the function "valid(block,blockchain)" is a pure function that depends only on its arguments, not on a implicit, side-channel access to a trusted time source.

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"?
member
Activity: 70
Merit: 10
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. Wink

smtp
member
Activity: 70
Merit: 10
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
legendary
Activity: 1120
Merit: 1152
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. :-(

You have to remember that the only reason blocks have timestamps in the first place is so that nodes can determine how long the last 2016 blocks took to mine for the purposes of adjusting the difficulty. That's it. Even two hours off compared to the 2 week/2016 blocks retarget period is only a 0.5% error. Also asking for the timestamp to be accurate within 30 seconds is pointless when the block interval is ten minutes; the whole idea behind a long block interval is to give the network time to ensure that a new block spreads to 100% of the nodes in a short time so miners aren't wasting their effort mining out-of-date blocks.

Another consideration is that if the allowed timestamp variance is that low miners are going to be using ntp to keep their clocks in sync. Now anyone with control of an ntp server used by a large number of miners, governments for instance, has the ability to split the network, with disastrous consequences. Similarly a screwed up daylight savings update (one that wrecks the computers idea of what UTC is) could throw vast numbers of computers +- an hour off relative to others, again splitting the network.

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!

It's notable that litecoin stuck with Bitcoin's 2 hour rule, and p2pool, even though it has a 10 second share interval, went with one hour.

Heck, I'm very slowly puttering around with a timestamping-via-bitcoin project myself, so believe me I'd love it if block timestamps were more accurate. But accurate block timestamps just aren't very important for Bitcoin's core purpose as a financial network.

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)

If you come up with something let us know. An easier way of messing around with custom transactions would be handy.
Pages:
Jump to: