bitcoin/application/user-program supporting own scripts available?

[smtp]

Hi

Are there bitcoin-applications available which support the  bitcoin-qt/bitcoind typical interface/transfers, but also support the possibility to define own/special txin-scripts and txout-scripts in each new transaction? Of course in this case I like that the application handles my private and public key accordingly to give me the correct hashes, resp. signatures which I may insert in the self made txin and txout scripts of the corresponding transaction.

smpt

[Peter Todd]

Hi

Are there bitcoin-applications available which support the  bitcoin-qt/bitcoind typical interface/transfers, but also support the possibility to define own/special txin-scripts and txout-scripts in each new transaction? Of course in this case I like that the application handles my private and public key accordingly to give me the correct hashes, resp. signatures which I may insert in the self made txin and txout scripts of the corresponding transaction.

smpt

Look into the Raw Transactions API first, but be careful, it's easy to screw up and accidentally lose your coins with it. Test whatever you are doing on testnet first. What are you trying to do exactly?

As for creating fully custom txin-scripts and txout-scripts, if you've read the "Scripts" page on the wiki you might not already realize that there is a set of standard transaction types that the network supports - any transaction other than that isn't easy to get into a block. As far as I know there isn't any easy to use software to create special transactions. When I've done it I've just edited the raw hex bytes produced by the raw transactions API.

[smtp]

As far as I know there isn't any easy to use software to create special transactions. When I've done it I've just edited the raw hex bytes produced by the raw transactions API.

THIS (the above cited first sentence) I only asked for: an existing (half-way user-friendly) program. Well, you may input hexadecimal data (for script code), but dislike all the time to use external (selfwriten?) code to compute the correct hashs, not to mention to compute the correct signatures needed in the txin- and txout-scripts. This should done by this program (like bitcoind or bitcoin-qt). So you may think as e.g. like an interface feature to bitcoin(qt)-client - if one would like/had it there.
smtp

[smtp]

there is a set of standard transaction types that the network supports - any transaction other than that isn't easy to get into a block.

Sorry, I like to disagree: Only a miner decides which transaction he likes to put in the just new found block. And I doubt that he will disgard (mostly) any transaction not of these only 3 "standard" types! :-) Honestly, he will not pay any interest of the script instructions but keep an eye for transaction fees.

smtp

[gmaxwell]

Sorry, I like to disagree

Just disagreeing with people who are more knowledgeable and experienced than you is not going to result in your enlightenment.  It will, however, result in you getting ignored.

Retep's advice was correct. There are standards transaction types. Non-standard transactions are not generally relayed or mined. The use of standard transaction types protects the network against dos attacks and makes it harder to trigger currently unknown bugs and makes it easier to fix bugs when found. And of course miners care about scripts— they must validate them, and if a script triggers a forking bug they'll lose their income.

If you'd like to experiment with novel transaction types, I strongly recommend using testnet as the standard transaction behavior is not enforced there and you can also mine your own blocks if you find the existing testnet miners are not being cooperative.

An "easy to use" tool for what you're asking for is not possible— writing your own scripts is fundamentally not easy. In fact, the only thing "easy" to do with custom scripts is to create unspendable outputs and burn coins. Perhaps one is possible for what you actually want, but you didn't describe what you're trying to accomplish.

[smtp]

Sorry, I like to disagree

Just disagreeing with people who are more knowledgeable and experienced than you is not going to result in your enlightenment.  It will, however, result in you getting ignored.

Retep's advice was correct. There are standards transaction types. Non-standard transactions are not generally relayed or mined. The use of standard transaction types protects the network against dos attacks and makes it harder to trigger currently unknown bugs and makes it easier to fix bugs when found. And of course miners care about scripts— they must validate them, and if a script triggers a forking bug they'll lose their income.

If you'd like to experiment with novel transaction types, I strongly recommend using testnet as the standard transaction behavior is not enforced there and you can also mine your own blocks if you find the existing testnet miners are not being cooperative.

An "easy to use" tool for what you're asking for is not possible— writing your own scripts is fundamentally not easy. In fact, the only thing "easy" to do with custom scripts is to create unspendable outputs and burn coins. Perhaps one is possible for what you actually want, but you didn't describe what you're trying to accomplish.

I try to accomplish the (easy) possibility to create "non-standard" transactions. If I would call your words true, then only 3 (or 2?) kinds of txout-scripts should appear in the valid blockchain. Here are the statistics for the currently 31 different (by opcodes) kinds of txout scripts in the block chain for the accumulated 3 blk000?.dat files (so you see the growth):

blocks=188529(0)  bytes=2097361271  TAs=4855613  max_ta=1322  max blk_sz=499261  max out=2002  deposits=11167813
21 effectively different deposit_scripts. Counters: 452733 10712112 3 5 1 1 23 2 601 2042 15 1 1 1 4 182 2 77 2 1 4
total size of script_table: 4085    size of script_heap:  243760137

blocks=210965(0)  bytes=2097295438  TAs=9549590  max_ta=1871  max blk_sz=499273  max out=2793  deposits=22202677
27 effectively different deposit_scripts. Counters: 687794 21509087 3 5 2 7 23 2 985 4206 15 1 1 1 4 182 2 325 2 1 4 1 1 1 1 1 20
total size of script_table: 4099    size of script_heap:  475068995

blocks=215171(2)  bytes=534251343  TAs=10728759  max_ta=1633  max blk_sz=496810  max out=1183  deposits=24980532
31 effectively different deposit_scripts. Counters: 711025 24263192 3 5 2 7 23 2 986 4602 15 2 1 1 4 182 2 337 2 1 4 1 1 1 1 2 78 46 2 1 1
total size of script_table: 4120    size of script_heap:  531679902

21696089 redeemed deposits   3284443 available deposits in blk00*.dat

So, please consider these facts, not the (undocumented) and not-well known wishes of developers. The big size of the script table is due to a lonely script of size 4006 (3rd position, occurs 3 times) -- else it would be at neglectable 114 bytes of total size.

... are not generally relayed or mined.

How to you know and decide this? Do you control or advice the miners?

And of course miners care about scripts— they must validate them

Interesting. There seems much more (power/influence) in the hands of miners than to me and most in the public BTC-users known .... I also wondered why the mining capability of the bitcoin-client was turned off (not only for inefficient I believe).

.... the standard transaction behavior is not enforced there

Is there undocumented enforcement code in bitcoind? I wonder what would happen if the miners' special programs would no longer work (block generation value too low, not enough fees, fun is doomed by rational thoughts) and no common mining-able client is in use by the normal users?

[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

[kjj]

There are nodes that intentionally relay non-standard transactions, and there are miners that intentionally mine them.  But most nodes won't relay them, and most miners won't include them.

[gmaxwell]

There are nodes that intentionally relay non-standard transactions, and there are miners that intentionally mine them.  But most nodes won't relay them, and most miners won't include them.

I'm actually not aware of any non-trivial miners right now that don't filter at all, even luke is somewhat selective.

The fact that it doesn't work for most transactions most of the time is in no way incompatible with there being a small number of oddball ones. Miners and people with relationships with miners have no problems. Some miners routinely use odd transactions for their own purposes or amusement. There is one pool that will mine a broader subset of them, if you include the right fees and directly hand the transaction to them. Some of the odd ones in the chain are from me, in fact... and, while I have no idea what tool you're using to count scripts there, I expect its not quite canonizing hard enough to only return 3, even if all there were were standard transactions.

How to you know and decide this?

It's not something I decided, it's how it is— though for good reason.

Do you control or advice the miners?

After a fashion, I do.

I also wondered why the mining capability of the bitcoin-client was turned off (not only for inefficient I believe)

Because the evil syndicate wills it. cough. uh. No, the integrated mining is still there, the knob is just hidden in the GUI but its visible and you can enable it from the command-line or in the config file.  But it's so slow to mine via cpu that you might expect to get one block on 3GHz cpu in about 135 years (and many people expect the difficulty to rise another 10x in the next few months, so 1350 years).  People were showing up very angry and confused that their cpu had been pegged at 100% for weeks and they didn't have a coin to show for it.  Sane mining using a gpuminer works exactly the same as it always has, and nothing has been hidden or changed about that.

Personally I'd like to see mining promoted in reference software— in the form of something with gpu/fpga/asic support and a GUI which promoted the lottery aspect of it a bit, with blinky lights, flashing numbers, and graphs and a best attempt so far gauge.  But it's all UI work, which isn't stuff I do.. and I doubt anyone considers it a priority right now. With it promoted as an unlikely chance hopefully people would be less surprised when they weren't rolling in the bitcents.

Is there undocumented enforcement code in bitcoind?

I can't figure out what even prompted you to ask that question. The software is open to all and the behavior we're talking about is well known and well documented, and considering that it was put in after a script handling bug exposed a vulnerability it hasn't been terribly controversial. If you're just trying to provoke angst with your antagonistic responses: troll elsewhere.

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.

[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

[2112]

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.

[Peter Todd]

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.

[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

[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

[2112]

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://bitcointalk.org/index.php?topic=133445.0

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

[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

[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

[gmaxwell]

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

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.

[Peter Todd]

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.

[2112]

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.