MintChip works in a request-response fashion.
The person who want money needs to create a request. (the request basically contains the MintChip ID and a Nonce, Nonce optional)
The person who send the money "signs" the request, which causes the mintchip to deduct money from the secure tamper-resistant storage.
The mintchip now produces a "response" ONLY valid for the mintchip who sent the request. The requester imports this response in his mintchip, causing the mintchip to increase the money in the secure tamper-resistant storage.

This is what is creating MintChips double-spending protection, without need to publish any ledger, since signing a request spends money, and the same response cannot be imported twice in the same mintchip since mintchip saves the Nonce of each response to its secure memory. Even if ambigious mintchips does not know the Nonce of all other mintchips, it will not accept a transfer destined for a another mintchip, thus you cannot send the same "coin" to 2 mintchips.

Whoever who writes the request can freely select the "Nonce" value, and writing a request does not need to use the mintchip, eg anyone can write a request.
The payer can change the Nonce value at will, but its important that the Nonce is unique across transactions of the same value to the same receiver, else you will burn money since the receiver cannot import a already "spent" nonce.

I think it can be done in a similiar way to this:
https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains


Basically, a secret must be selected, such so the sender of mintchip-currency needs to publish the mintchip-currency in the blockchain, to redeem his bitcoins. The owner of the receiving mintchip only needs to scan the blockchain and then import the message in his mintchip.

The problem is that this require RSA PKCS#12 certificate checking against MintChip CA certificate.
Try to figure out something.

"Double spend = same input, different outputs."

You would still need to reconsider the changed tx fee. That would require you to change the amount of the "change" adress, and/or add new inputs and/or outputs to the transaction (if the too-low-fee transaction also included inputs with too low value to be able to increase the fee) so the new fee add up correctly in equation.

Its hard to check in a safe way. I think a tx expiration feature would be better then.

Etotipi (just cant spell your name):
>>to have to share my personal information and transaction details with the entire Bitcoin network, or any subset thereof, just to have my transactions arbitrated.

Its required to share personal information and/or transaction details if you want to have your transaction arbitrated. Its same everywhere, if you pay in cash IRL and you want to have the deal arbitrated you will have to provide personal/transaction details and sign a contract and much more. Same with a third party arbitration service, you will have to provide them with your personal details and transaction details.

>>which may involve contacting both parties and collecting documentation.

Not required. The goal of the voting arbitration scheme is that buyer and seller SHOULD provide documentation before executing the deal, and if the seller's information is incorrect, (for example if the buyer and seller agreed on 25BTC for 50$ on paypal and instead sends 10BTC and writes "want 50$ on paypal for this") seller should REFUSE transaction and let it go back to sender.




Its same IRL too. You can either pay in cash, but then if you are scammed, the cash is lost. Cash is also anonymous.
Or you can pay in bank card, and then if you are scammed, then transaction can be chargebacked by the bank, but card is nonanonymous.


Since "the bank" in bitcoin is all nodes collectively, I think a voting scheme is best here. In this way all nodes collectively decide if the transaction should be chargebacked or not. Then you really get a decentralized "bank" which can do escrow, arbitration and control the money flow.

If you read the thread, you will find that "secure transactions" are entirely optional, you can in other words select if you want to send a "normal" transaction or if you want to send a "secure transaction".
Because disputes of secure transactions disturb the network very much (by nagging all users that have selected to partipicate in voting with a popup or a message or what your client do), they will be very expensive, with a tx fee of 10BTC or something like that.

Basically, you send a transaction, AND in this transaction a message is written:
Examples:
" Nokia 3310 + shipping to blabla blablasson North Street 10A XXXX XX New York "
" 50$ on paypal acct blabla-paypal@hotmail.com "
" Custom homepage project with a green template, upload to FTP on www.yourhomepage.com "

Then, the receiver needs to approve the secure transaction (or he can refund it), with a response:
" Here is your 3310 on way: http://www.large-freight-company.com/tracking.php?track=US395359235628974 "
" Here is your paypal money. Did a print screen: http://www.image-host.com/paypal_print_screen.jpg "
" Here is your custom home page: http://www.yourhomepage.com "

THEN the sender of money now either approves transaction OR he "dispute" the transaction

If the sender now dispute the transaction, ONLY those that have selected in their bitcoin client to partipicate in arbitirating of disputed secure transaction, will get a popup in the bitcoin client:



You can then look at the evidence the receiver posted - in this case a screenshot of a sent paypal transaction, and then select to:
Defer the vote - which means you will not partipicate in this particular vote and not send out any votes.
Vote in favor to the sender - Your bitcoin client will compute "sender" vote and send out with PoW.
Vote in favor to the receiver - Your bitcoin client will compute "receiver" votes and send out with PoW.

And the outcome of the majority (where more CPU power = more votes) will decide which adress the money will go into.

I have a idea of how arbiritation can be done: With secure votes.
I have put a idea of a forum, but it didnt got any replies. Instead of writing the text again, Ill post a link to the thread:
https://bitcointalk.org/index.php?topic=4856.0

Basically, all opted-in members in the bitcoin network votes on how the transaction should end up, and all members are rewarded for voting correctly which means theres incentive for really verifying the details of the transaction and make sure arbitirating are done correctly.

I understand the problems. Thats why the taint list should be entirely optional, and that theres not a central authority of taint list, instead each other uses any taint lists they want to use (like DNSRBL's).

The problem we need to solve is that exchanges start locking accounts because the money come from a stolen source, like paypal does.

This will hurt bitcoin webshops, that have delivered the goods but have got worthless money they can't do something with, because nobody wants it, altso the webshops gets their other money locked too. Look at the person who got 7BTC stolen money into his MtGox account and his whole account was locked, even with all other bitcoins.

Thats why we need some easy feature, that indivuals can use to reject any "stolen" money. I saw a handshake idea in the forum that prevents sending money to somebody that does not want it, that would be a good idea, then the money can be rejected before it even are transferred.


What about whitelist then? Same feature, but instead you whitelist trusted senders and nobody else can send money to you.


Try to brainstorm about this, it must be some solution there that prevents peoplr from getting their exchange account locked because the money was stolen.

Now im not talking about that single piecie of stolen money when talking about locking the account. Think of 1BTC that was stolen, and I depoist it in my 1000BTC MtGox account. Now 1001BTC is confiscated if I don't have a good explaining of why I got 1BTC of stolen bitcoins. Thats why we need taint list.

So people receiving stolen money can prevent it from being used, and webshops can prevent getting stolen money into their webshop wallets, because even 1BTC of stolen money can lock the webshop's MtGox account with tousands of BTCs, even if the webshop would happily return that 1BTC to the rightful owner.

Holiday: You would notice if there was such a "blacklist" of certain notes. We have had some in a suburban area here in sweden. The bank putted up notes on windows to shops telling people "Not to trade with any 500SEK bills beginning on digits XXXXXX" and the note had a image of a 500SEK bill with its first digits of the serial number circled.

Probably a robbery in the local bank so they made sure to recover the money by "blacklisting" it.


Hollyday: I don't understand? Why boycott MtGox? Its not their fault that people hack other merchants/echanges and steal their coins/private keys.

But what should we do? MtGox and such exchanges are locking the accounts of people who use "stolen coins".

We need to have something so people can avoid any coins that for example MtGox has deemed as "stolen".
If this feature would be included, most merchants would have a "stolen coins we don't accept" list on their website.

Its the same as IRL. When there has been a big robbery (and with big I really mean BIG robbery), the bank publish a list of serial numbers that is "blacklisted" and merchats are told not to accept these notes/bills (Often in the form "Do not accept a 500 SEK bill that is beginning on 4567 or 8723"). And if they accept, the bank will refuse to cash in their notes/bills to their company account.

DeathAndTaxes: I think you misunderstand now.

The idea of the Taint list is not to have some central authority.

Anyone can host a taint list, like those DNSRBLs. I can host a anti-spam DNSRBL. You can host a DNSRBL.
Then everyone is free to use the DNSRBL or not. So you can select to use for example my DNSRBL in your mailserver, and reject mails to your server based on my criterias.

Same with taint list, you select which taint lists you want to use, and you reject coins to your account (=all adresses your bitcoin client recognize as yours) based on these lists.
And taint list does not only need to include stolen coins, it can be "bad" coins in other ways.

The *each end user* decides if they want to use taint list or not, and downloads the taint list they want.


"Who decides if a coin was stolen?"
You decide. Taint list is a tool that lets you reject depoist in your account that have been in touch with a specific adress.
You decide if you want to download a taint list from Bitcoinica listing addresses that Bitcoinica had their coins stolen to.
You decide if you want to download a taint list from me where I list adresses where coins were stolen from me.
You decide if you want to download a taint list from MtGox which MtGox list addresses they deem contain "stolen coins" and not accept any exchanges for.


About TX fees: How long do you need to wait for a small 1:1 transaction to be admissable on the network without fee? Maybe the taint list feature could wait so long.

dooglus: Yes, but we still need to have incentive for mining, regardless of if the funds are stolen or not. And yes, you can send your coins to null and put the whole coin as fee, but then it would be random if you get the coins or not. Another miner might be lucky and "pick" up your coins.

I still think that MtGox wouln't "care" about stolen TX fees. They just track everything until their coinbase transaction, and not going any further. Since of the nature of TX fees, you cannot know which part of the coinbase that is stolen.

The proposed taint checker list is for ordinary people that want to avoid ending up with thier exchange account locked and/or confiscated due to stolen coins.

Nope. Coinbase will never be tainted, since mtGox and such does not consider them tainted. Its possible for to example MtGox to dig deeper into such blocks and check the taint, but that would punish the miner because the miner cannot help that he got a tainted coinbase as reward.

I don't think exchanges like MtGox and such would lock accounts belongning to miners that mined a stolen TX fee. That would be counterproductive for the BitCoin network since it discourages mining. Miners can also not say no to a TX fee, the reward (50BTC current) and TX fee are melted together and cannot be separated without tainting both coins if we were for checking tainted TX fees.

So I agree with you, no taint checking on fee's.

Since the return transactions are always 1:1 (1 input, 1 output), I dont think they will cause a tx fee so often because the transactions will be small in regards of "byte size", compared to the money value.
And in the cases they would cause transaction fees,  the coins could be simply locked (like you owned the coins at the time at when you added it to taint list) instead of sent back. Then the node operator can force a sendback at his own expense. This can also be accomplished by a rpc command: "CleanTainted" which will send back all coins that are currently tainted and owned by you. (not including any untainted coins in a tainted adress owned by you)
This can then be precalculated, so it knows in advance if the transaction requires a fee, and then lock the coins instead of auto-sending them back.

Coins can be sent back at the first adress in the transaction spending the tainted coins to you.

Also to make this clear, there is 4 states a coin can have regarding tainting:

1: Untainted coin in a untainted adress: The coins have never touched a adress that matches a condition in the taint list. The adress that the coin is placed, is not on taint list. Those coins MAY be used as inputs.
***In other words, the coins are completely clean***
CleanTainted will NOT send back these coins.

2: Untainted coin in a tainted adress: The coins have never before touched a adress that matches a condition in taint list. But your adress that currently are storing the coins are tainted. ANY coins in this adress will NOT be used as input.
This means that anyone that receives coins from this adress from you (if you manually remove the adress from YOUR taint list and then resend coins), and also have downloaded the same taint list, (lets say "MtGoxTaintList.txt") will reject your coins.
***In other words, you have added one of your own addresses to your taint list, but the coins themselves are clean***
This can happen if you download a taint list from somebody and this taint list contains one of your adresses.
CleanTainted will NOT send back these coins.


3: Tainted coin in a untainted adress. The coins have touched a tainted adress, but your adress is not tainted. This means this specific coin will NOT be used as input, but any other coin in this adress MAY be used as input as long as it not tainted.
***In other words, the coins have touched a taint-listed adress***
CleanTainted WILL send back these coins.

4: Tainted coin in a tainted adress. The coins has touched a tainted adress, AND the adress currently storing the coins are tainted too. No coins from that specific adress will be used as input.
***In other words, the coins come from a taint-listed adress, also, one of your own adresses are listed too***
CleanTainted WILL send back these tainted coins. (not untainted coins, see case 2)



Such a tainting system, will allow people to create and publish taint lists. Think taint list like these URL Blacklists and lists of malware-infected sites out there. You can hand-pick the best lists of tainted adresses, you can download them all and then auto-update taintlist, or you can modify the taint lists, for example removing (whitelisting) entires before importing the taint list.
Or you can create your own taint lists.

Its up to each end user how they use the taint list feature.

Also, taint list will not only list "bad" adresses. Taint lists can for example list all adresses that have been published on the internet (like those DNSRBL's that list every end customer that is not expected to have a mail server) or whatever. Its up to each user which taint list they download and use.

I got a suggestion to remedy the "stolen coin problem".

Make like a list in the bitcoin client, that you can freely fill and delete with bitcoin adresses.
This list could be linked to a file on your harddrive that autoupdates the list. (so you could automagically update the taint list by removing or adding entires by writing to a file on your harddrive, like taintlist.txt , so you can update it with a scheduled task or cron script at regular intervals, or have a "report stolen coin" feature on your webshop that populates the receiving end on your webshop taintlist.txt with the adress in question)

Everytime a payment is received, bitcoin checks the whole trace (blockchain) for the whole chain of the coin until it reach the coinbase.
If a adress on your list is found, the payment is rejected by sending it back to the sender in complete, without involving any change, thus it does not taint your adress.
Also, any event that would indicate that you received payment, would not fire. (so any webshop script would still wait for payment).
If this becomes too computationally intensive for the clients, the taint list could have some sort of "depth" option that allows the taint list owner to set how deep it will check for taints, and -1 would then mean "to the coinbase".
The depth could be set per address tainted, so you can select a depth depending on how "dangerous" the address in question is. (but it will always search deep as the address on taint list with highest depth).
So adding addresses with a depth of 0 would make these addresses blacklisted, so money coming direct from these adresses are sent back, but not if they passed a untainted address before reaching you.
depth=3 would mean the latest 4 adresses the coin passed may not match the entry in taint list.

Note that this is a feature that everyone would be free to use or not use. Keeping the list blank would make the bitcoin client behave as usual.
This does not change the network at all, since it would be the users themselves that elect to download taint lists and populate their lists with. Simply, the taint lists is "I DONT want to receive ANY coins that have been touched these adresses:"


Then MtGox and other people, such as companies that get their funds stolen, can publish lists of coins they will groan upon, and then ordinary bitcoin users could download these lists and populate their taint lists with. MtGox and such can select to keep "stolen" money for the purpose of recovering it to original owner, by not using taintlist feature at all, thus accepting all payments.

The taint list could simply have so you can even "add" a list to the list, and "remove" a list from the list.
"add" a list to the list, would simply add all adresses in the selected text file, checking for duplicates, to the taint list, keeping any records already in taint list.
"remove" a list from the list, would simply remove all entires found in taint list, that match all entires in a selected text file. (This is good if a trusted web site says these coins have been recovered).

Also "addtaint <address> <depth>" and "removetaint <address>" could be added as RPC calls.

Also a new event could be added, like "checktaint <receiveaddress>" that will return you with a list for your backend system that someone attempted to send you tainted coins that matched <taintedaddress> on your taint list, and coming from <senderaddress>, that was sent back.

If you own a private key that correspond to a adress on your taint list, the client will never use those coins as inputs. All coins contained in that adress would be consideded tainted. The balance would show the balance excluding coins in any tainted adress, and those adresses will be highlighted in some way in taintlist, so you can easly remove these adresses from your taint list.
Same would apply if you own any tainted coins, but only those coins would be tainted, not the whole adress you own that the coins belong into. (and the adress that "triggered" tainting of the coins you already own would get highlighted in your taintlist with another color)

Taintlist would simply be for ordinary people to not get stolen coins into their account and then get their account locked at MtGox and such.

amencon@page1: "Do the people that find themselves in possession of laundered stolen coins have the same opportunity to protect themselves?"

Yes:
1: Don't publish your public keys. Keep them as secret you would keep your private keys.

2: Again: Treat your public keys as they were your credit card numbers. Would you enter your credit card number at some random untrusted USD to EUR exchange? Would you give your credit card number openly on this forum? Would you give your credit card number to some random wanting to give your money?

3: Yes you can give public keys. But treat them as your credit card number. ONLY give them to trusted people. Think of trusted people as like those nice webshops that you trust and know have good reputation. You freely give your cc to them.

4: Only deal with trusted indivuals.

5: Once a key is used, consider it void. After a adress has been used for a legit transaction, NEVER ever reuse that key. NEVER ever collect
any coins that may randomly fall into that adress. Toss away the private key after the coins has been spent.
(Because the public key go into the blockchain and is published and leaked.)

6: If a public key does leak, make sure to claim all coins before any new coins appear at that adress, and then toss away the private key to the leaked public key.

7: If you get unknown coins at a adress, use a client that allows you to select coins, to make sure to only select non-stolen inputs, to claim all coins from adress.

8: If, and ever if, unknown coins ever get mixed with your own coins in some way making them unseparable without tracing you to the stolen source coin, toss all those coins overboard.

Yes, thats a perfomance saver. The client doesn't verify blocks older than 24 hours. Think that the leeway of accepting blocks with bogus timestamps is +-2 hours, you cannot broadcast a invalid block that will get accepted by network for being too old to be verifyed, if you don't own at least 51% of the hashpower.

Anyone can verify the whole chain, it just that the stock clients does not verify old blocks because ECDSA verification is too computationally expensive.

So in short, you can be sure that blocks that skips verification because of being too old, has been verifyed by the majority of the network some time when the blocks was fresh.

So owning 51% of the network is always and have always been a "ownage" of the network and you can do whatever you want.

bueadept: Theres no need to time-limit trusted adresses.
Instead this responsibility lies on the merchant.

To get a realistic trust, the merchant needs to take the rate that was set on the date where the trust in the adress was purchased, and then convert back using today's rate.

For example, if a BTC today is 10$, and in 6 years, 1 BTC is 500 000 $.

Lets say I purchase a adress for 10 BTC (worth 100$). I save the adress in 6 years, and then wants to purchase something instant.

Merchant now does this:
Look up the exchange rate for 1 BTC for when the adress was purchased 6 years ago:
We get Rate = 10$

Look up the exchange rate for 1 BTC today.
We get Rate = 500 000 $

Now we take the TODAY rate divided by OLD rate:

500 000 / 10 = 50 000.

This is the trust reduction index. Now we take the trusted amount, (10 BTC) and divide by the trust reduction index: 10 / 50 000 = 0,0002

This means the trust in the adress is currently: 0,0002 BTC

*********
Lets back-calculate: TODAYs rate * Trustvalue in BTC = 500 000 * 0,0002 = 100$, which is the real value.
*********



This means the adresses will always bear the correct trust regardless of deflation, without them expiring completely, which would be devasting to users that really have purchased a trust in a adress.

Now I understand. I tought you meant that you should replace "walletpassphrase" with your actual wallet passphrase.
Since when people write in this way, its assumed that you should replace it.

Like:
"For logging in to the binary program, type binary -u=root -p=rootpassword" and then its assumed you should replace rootpassword with your actual root password.

It would be worth noting it in the thread start that you should NOT replace walletpassphrase with your actual passphrase, so people dont misunderstand it. They might think bashrc is protected in some way then.

theymos: why add the private key AES encrypted when you just can SHA256(password) (like mini-private-keys) and use that as private key?
Then you tell the legit whoever that should be able to access those coins on how you redeem them.

then the attacker looks in ~/.bashrc and voila´ your wallet password on a silver plate.

Best thing here would be to create a account in the OS where all bash history and bash logs are off, and using that account for bitcoining.
Even better, use a separate liveCD dist optimized for bitcoining, then bash history is nothing to fear, just shutdown the computer when done and you are sure nothing remains of your session.

I dont understand this: How do we know if the block is coming from a misbehaving client (eg which sends "orphan" blocks on purpose), or a block that comes from a slow miner, so the block cannot go into the blockchain because that node was too slow and another node was first, and thus that block becomes orphan?

I know that miners dump the block they are currently working on and begin working on next block if someone races before the miner and completes a block, but this case with "legitimate orphans" can occur if 2 nodes complete a block in nearly the same time.

A legitimate orphan occurs when:
1: A miner A completes block before miner B
2: Miner B completes the block before getting notification from network that miner A completed the block
3: Miner B sends out the orphan block because he didnt know the block was orphan.

Now miner B would get banned for one single orphan block.


Maybe its a bit harsh to put a score of 100 on a orphan block. Maybe a score of 40 is better, 3 orphan blocks in 24 hours is a bit much.
I guess the score are reset each 24h period?

Then miners who know they have sent 2 legitimate orphan blocks (because they got the notification that a block was completed after he sent out his own block), can stop mine until 24 hours have passed, and thus avoid getting banned.

And if this happen regularly, for example 2 periods in row, the mining client could automatically add a little delay in the mining, so the mining client avoids his "twin node" which mines a little bit faster.