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

[1714700084]

1714700084

[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.

[Peter Todd]

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!

[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

[2112]

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.

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.

[gmaxwell]

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**

[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

[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

[DeathAndTaxes]

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.

[deepceleron]

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

[gmaxwell]

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.

[smtp]

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://bitcointalk.org/index.php?topic=134843.msg1449369#msg1449369) (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

[gmaxwell]

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.