Isnt the 2 hour "leeway" only for which times a node will *accept* a transaction?
For verifying a timestamp, a bogus timestamp would be very visible, even if its accepted.

For what I have understand, the node that makes a block (mine), affixes *his* system time to the block before working on it, and since it takes 10 minutes to work on it, the timestamp will be 10 minutes behind, and so on.

So each block then have a timestamp that is about 10 minutes apart.
So if we have this:

block1: 12:00:00

block2: 12:10:00

block3: 12:20:00


a transaction appearing in block2 could then the verifyer assume that the transaction was done on some time between 12:00 to 12:10. If the node who did block2 is bogus (eg emitting false timestamp for his blocks), you could use the blocks after and before this to verify how much bogus the node who did block2 is.

pointbiz: The best thing here, is to provide a simple API on top of the standard API:


My suggestion on a simple API, consist of this:

First you take a link, a so called "callback url", payment amount, put your own bitcoin adress before it with a @ between, and encrypt it with RSA, using a public key owned by Strongcoin. This encrypted link, when ASCII-armoured, is base64. Remove the headers so only the base64 content remain. Convert it to urlsafe_base64 (eg replace / and + with - and _), then send it to the API.

Like this:
15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC@0.01@http://www.mysite.com/downloads/file/music.mp3

Then encrypt this with strongcoins public key, and then urlsafe_base64 on this.

Then you send it to strongcoin by providing a "a href" saying Buy now, which links to say:

http://www.strongcoin.com/api/?request=WoreigtnpEopqgituqLirutLiuoqiurtDqgntoEoqiptonpaongupAaigtaopipNtaponaogbapYtnpnpqOeoiuapoinUangpatWnppaooitghtOgagoppUoughjbnnzzLmcgotviotpioDatuoapcmqpBslmxksEdoeltjbduekeSlfigugUtjwklsldkfugyghRieowldjkdhfyPyeuiwowlwRdmvnbueoIepwls

Strongcoin displays payment adress and instructions on how to do payment on the linked page, and then constantly refreshes using META REFRESH until payment is received (or use AJAX but avoid AJAX for backwards compatibility reasons).
When payment is received, Strongcoin simply redirects to the adress that was provided encrypted in the "request" parameter.

Then its up to the original site if they want to save a cookie, allow 24 hour access or whatever upon first visit on the "callback url".
This can even be used with a static HTML pages if someone want to host a static page without any dynamic scripts.

And then the standard API is simply kept asis. Then those that want to code own security, can do it with the "standard API", and those that want a simple payment system can do it. And the "simple API" can also be used with temporarly urls, security controls and such.

bwagner: Actually a good idea. Then these live-CD-systems with bitcoin could work more well, and you have access to your coins on *any* computer with bitcoin, as long as you know your passphrase.

Like this:
When you start the bitcoin client, you enter a passphrase/password, like:
"HereIAm".
Then, it would generate SHA hash for HereIAm.(number from 1 to 10 000) to generate a new adress. Note that the number 1-10000 is random to increase anonymity, and it will never use any other number, since then some coins would be unspendable. No track of used adresses should occur, the client is simply allowed to "reuse" adresses if its just lucky to pick the same number.

(For webshops/exchanges, the webshop/exhange just check that a adress is "settled" before reusing it for a another customer. With "settled", I mean that goods have been delivered for that adress and all payments have been received for that adress)

To find out coins, it could generate adresses from hash of HereIAm.1 to like hash of HereIAm.10000 and check which coins belong to these, while downloading blockchain. Then it simply saves it to RAM (this takes only 2,4 Mb)

Then you would never need to save any wallet.dat, you simply enter your password/passphrase at startup, in any bitcoin client.

Of course, if 2 people use same passphrase/password, they would share the same wallet, and spend each other's coins.

I agree with the robustness principle, that programmers (like me) should implement error checking and handle all errors gracefully, which most, like me, do. But what I also say, is that those inputting things into software should make sure to not input bad data.

And what I say, is that if a software fail due to bad input, and the programmer forgot to implement error checking, is still the fault of whoever that provide the bad data, not the fault of the programmer or the software in question.


About web development, it is in fact easy to do web pages that works in most browsers, including IE.
Validate your pages against HTML 3.2, no CSS and no JS, and your pages will work wonderfully in most browsers including old versions of IE like IE 4.0.


bluefirecorp: 23/100 and a big "FAIL" and the text "You should not see this at all" behind FAIL.

-----

But now we are not talking about badly rendered pages, which can be acceptable in most cases.
What im talking about now is:
The browser CRASH when visiting bitcoin wiki thats a unacceptable fault of the wiki! The wiki are sending something that causes the browser to CRASH, be it something in SSL handshake, be it something in HTML code, be it whatever. But please fix it!

I am a programmer, so I can explain:

Lets say I write a custom bitcoin client that allows you to share 10 bitcoins to Y people evenly.
And a stubborn user/client are writing 0 as Y, the application take 10/0, it don't compute and the application crash.

Its not the application's fault that you/the client wrote 0 as Y. Its the fault of whoever that sent the erronous data. The application didnt expect you to write 0 people to share your 10 bitcoins between, it tries to compute it, OS returns "Cannot divide by 0", the app croaks and gets a runtime error -> crash.

And do you call this "normal and valid"?
http://validator.w3.org/check?uri=https%3A%2F%2Fen.bitcoin.it%2Fwiki%2FMain_Page&charset=%28detect+automatically%29&doctype=Inline&group=0


Its really a problem in the wiki and not the browser. Please understand it.
And how are you not hating IE when you say that its "faulty tools" and that the browser sucks?



"consistently fail during normal operation."

Not consistently. If it crashed on every site I visited, I would wonder if IE is a good browser or not and switch to a another one. But now, its does not consistently fail, it fails *only on bitcoin's wiki* and nowhere else.



ineededausername: Because I like IE. Whats horrible with the browser? Its the browser that works with most pages, but not with the wiki.

Okay, so you say, that if the wiki is sending bad data to the browser, that the browser does not expect, and the browser crash, its the browsers fault?

So if I fill up my diesel car with Petrol 95octan and the engine gets broken forever and the car engine need replacing, then its the car's fault that it didnt accept "bad input"?


I understand that you hate IE, but thats not the topic of this discussion. The topic of this discussion is a serious bug in the wiki that crash the browser. It can happy with ANY browser. No browser is completely 100 % crash resistant. If the browser gets something down the throats that it didnt expect, it crash, simple as that. The problem lies in the wiki, NOT the browser. The browser are only trying to intepret what the wiki are sending, and the things the wiki sent was something that didn't compute.


BTW, updated the problem description in the main post. Found out a new era of the problem, that the problem appear in ALL fresh browser windows (not "open in a new window", but launching IE from the desktop), when I visit the bitcoin wiki, regardless of if I click a wiki link or enter *any* url that goes to the bitcoin wiki.

Not if the nail is harder than the hammer :-)

It would be a browser problem if this appeared on multiple sites, in the same fashion. Since this appear:
ONLY on bitcoin wiki,

its the wiki that isnt in a healthy condition.

netrin: If its the browser's problem, why does this not appear on any other sites? The last time I got the message was like a year ago and im a very active internet user (7 days/week, more than 12 hours/day) so its not a problem of the browser.

Dont blame the browser. Its the wiki thats is crashing the browser.

I dont know if wiki discussion belong here but I could not find a better forum so I post it here.
Mod is free to move it into right place.

And to the topic. The picture says more than tousands of words, and this appear ONLY if I click a link or visit bitcoin wiki , regardless of the URL to the bitcoin wiki, if I visit it in a NEW FRESH browser window.

Looks like something on the wiki is REALLY badly coded.

Browser version: 8.0.6001.18702



ENGLISH version of the message:

cbeast: Exactly what im talking about.
This could be even included as a patch to the original client, since no changes in protocol is needed (you don't even need to disable IsStandard check), simply a button/menu alternative "Let bitcoin network notarize any document", and you get a large textbox to paste anything you want to notarize.

When a block gets confirmed, we have a time window of 10 minutes, where the notarized document will appear.

Combine this with a "real" notarizing service like: http://www.timemarker.org/en/ and you get second precision in the service.

The "timemarker.org" service then makes second precision, but timemarker.org would not be as trustworty as you think since they don't have many users, so even if you dont cheat, a verifyer can say that you cheat and you cannot prove you don't cheat.
You then combine this with a 0BTC transaction on bitcoin, and get both very high security, since bitcoin is really hard to cheat, but also get second precision for the timestamp.

What you could do, is simply timestamping (0BTC:ing) the hash of timemarker.org signature including the timestamp data, using the timestamp from timemarker.org as transaction timestamp, and including both in your data that was timestamped.

But what about transaction fees? If we send 0BTC into a adress, it would never make it into a block unless a miner is honoring non-fee'd low transactions.

What about using bitcoin for trusted timestamping?

Found out this: https://en.bitcoin.it/wiki/Mini_private_key_format

Apparently, anything can be used as private key (like SHA("haha") as private key, and then a public key can be generated out of this).

Then, if I take a document, lets say a legal document, some important server logs, bookkeeping records in a company, or anything else that needs a trusted timestamp. Then I take SHA() of the document.
Then I use the result of SHA() as private key (appending zeroes if its too short, and truncating if too long), generate a adress and publickey out of this, transfer X number of BTC (high enough to avoid any transaction fees), to this adress.

Then I use the SHA() private key to transfer the funds back.

After this, I publish the timestamped document along with a link to blockexplorer to verify it.


Now I have created a record in the blockchain, that, anyone having access to the document in question, can check the timestamp in this way:
SHA() of the document in question. Then create public key out of this private key, then make a adress out of this. Check with blockchain which are the *earliest* entry of this adress. The timestamp of that entry is the timestamp of the document in question.

Since the address is empty since we transferred the funds back, theres no funds to be able to withdraw from someone that has the document in question and can generate the private key.


How accurate is bitcoin timestamps and how can they be manipulated?
(either by the one timestamping the document, in effort to defraud someone with a future/history marked document, or some external adversary in order to gain any fraud convience, like manipulating timestamp so a important document seems to be issued after a identy theft credit block is ordered on a specific social security number in order to invalidate the document?)

Today in the newpaper, there was a article about bitcoins, and how its used for drug trading and swedish goverment has plans on making the currency illegal.

It might be of interest for bitcoiners, but I don't know where to place the thread, move if neccessary.
Here is a link to the article:

http://www.gp.se/nyheter/sverige/1.682529-droger-kan-bli-ny-natvalutas-fall

Also the locale on the computer can be incorrectly set, so thats an bad idea too.

I think the best idea would be:
Disallow multiple ,/. completely.
Allow only one single , OR a . in a amount, and treat it as decimal comma.

so:
1,000 = sends one BTC
1.000 = sends one BTC
1,000,000 = invalid
1.000.000 = invalid
1.000,000 = invalid
1,000.000 = invalid
0,1 = sends one tenth of a BTC
0.1 = sends one tenth of a BTC


Thats much better, since if a US person accidentially enter for example 3,000 as digit grouping to sent three tousands of BTC, that would fail on the "good" side since only 3 BTC is sent. The person can easly correct this by sending 2997 BTC more.

So thats a good fix to this bug.
I think using locale-specific functions can be dangerous in financial software at all, imagine someone who installs a US version of windows or imagine a swedish person visiting a US internet cafe with a USB stick with bitcoin on it.

Yep, but its arranged in a situation where both survelliance each other.

So the DLL/SO survelliances that the EXE requesting API access is correctly signed and not modified, and that not critical parts are modified, and the EXE checks that the DLL/SO is not modified.

Also both the EXE and the DLL/SO can check itself in a way too.


If its too tough to make secure, you could have 2 identical DLL/SO, that survelliance each other.

Gnaffel: No. What he are talking about, is that you need to allow bitcoin clients to access the internet, eg you need to open port 6667 to irc.lfnet.org and port 8333 to * in your payment gateway, hotspot, firewall, whatsoever thing you are using to prevent users who have not paid from accessing the internet.

Also beware of tunneling users, in other words, users who SSH's or SSL's over 8333 to bypass payment and surf for free. A wise option in this way can then be to have a empty bitcoind running (with no coins inside), which your firewall NATs all :8333 traffic to. This bitcoind will then be like a "proxy" to the world. The user does not need to send the coins to that bitcoind, thats bitcoind only connects the wifi bitcoin network to the wide bitcoin network. and passes transactions further and back. Then you don't need to have 6667 open. (Or you could set up a fake IRC server which all IRC traffic is NATed to, which only have one channel #bitcoin, which reports your gateway, eg 192.168.0.1 as a bitcoin node).

Dont allow rpcallow=*! Its enough that they get a connection to a bitcoin node.

I think a better idea here is:

You have one CARD keypair.
And one ACCOUNT keypair.

The ACCOUNT keypair is not available on the card, only on computer, and the CARD keypair is available on BOTH card and computer, BUT the private portion is saved in a way that does not allow it to be extracted (only used).

When you do a purchase, you insert the card into the POS terminal, and the POS terminal searches for some of your coins (The card could also save some transactions for faster search), uses them as sender, sends the coins you wants to purchase for to merchant and receives change.

Since the private key is "locked" into the card (so it can only be used, not copied), any crook merchant cannot copy the private key and use it later when your'e not around.

A crook merchant COULD debit your card more than agreed purchase amount like debiting 100$ but showing 1$ on display, but thats true for cash too.

If you give a 50 $ bill to a merchant for a 30 $ item, he could simply refuse to give a 20 $ bill back. Its the same problem. You need to trust the people you are doing affairs with. And in case its a crook merchant, you simply police report him and the police does it's work.

Thats why you should never carry more on your card than you are prepared to lose. So you can carry lets say 3 cards with you, one card with 10BTC, one with 50BTC and one with 100BTC. This will be like bills in a wallet. You give the smallest possible bill to merchant, in case he is a crook.



But the big bonus is that you can PIN protect the card, AND if you lose your card, you can "ban" the card in this way:
Simply move ALL coins currently saved under CARD key to ACCOUNT key. Now the card is empty, so even if someone figures out the pin or physically hack the card, theres no coins on card.

I think it would be better to divide the client in 2 parts:

For windows: A EXE and a DLL.
For linux: A executeable and a SO.

The DLL/SO file contains the core functions for bitcoin, like chains, rules, mining, packets sending and such.  The DLL/SO is *NOT* locked in regards in which scripts that can appear in transactions, but the core functions will never allow the bitcoin client to change its inflation rules.

The DLL/SO is then locked in a way so *nobody* can update it while bitcoin is running, and the file is signed and checked by the bitcoin client prior to loading. The bitcoin client and the DLL/SO should also have a function preventing the bitcoin coin from updating the DLL/SO althogheter, even if you could completely decide which code is in the EXE/executeable.


In this way, we can have secure auto-update of the bitcoin, WITHOUT any fear that the core rules might change because of a hacker attack. To prevent stealing of coins from users, we could have the proposed signature scheme.

So in other words, the developers can send out autoupdates regarding non critical parts in the client, but nobody, not even the developers, can send out updates that change the central rules in the bitcoin.

I think this would be a good idea. Not only for backup, but allow user to "create" a password (enter a password) and that password is used to create ONE bitcoin adress.

The good thing for this is situations where theres no local storage, for example live-CD systems and such. It would be bery good to be able to embed a bitcoin client in a such system, and the user just enter their password and everything is generated and fetched based on the password.

No not a reputation system.
Instead more CPU-power = more votes.
More correct votes = more money.
More incorrect votes = less money.

And the system is not based on reputation, rather that all nodes that have selected to partipicate in votes, gets the option to vote the transaction in favor to the receiver or in favor to the sender.


The reason is that using a escrow requires parties to atleast trust the escrow (in case óf devrandom's escrow system) not to release the funds if the seller is fraudulent (eg the escrow is not cooperating with fraudsters).
The vote system does not require any trust at all. And the vote system is protected by the same fundamentals that prevents double-spending. (Eg you need to control more than 50 % of the network to get through a fraudulent secure transaction)