carp: No, not in the transaction. Either you create a secure transaction or a normal transaction.
If you create a secure transaction, the receiver has to accept it and affix evidence of having sent the product.

Then if you select to dispute the transaction, *everyone* in the bitcoin network who has opted to do voting will vote. Its not a requirement to vote, even if you have opted to do so.

To give a incentive for unknown indivuals to investigate transactions, a reward will be given to those that vote correct in a secure transaction (where correct are defined as majority). To prevent that people vote at a random just to gain extra money, a little cost must be paid for each vote sent out. If you then vote correct, you get back this cost PLUS the reward. If you vote wrong, your cost gets into the reward pool to be shared to other voters who voted correct.

To prevent people just voting like majority, the votes could be hidden in some way until the vote is end, then they are revealed. Maybe someone can come up with a solution to this.

Its like http://www.phishtank.com which gives "reputation" to those that votes like the majority and gives dis-reputation to those who not votes like the majority.

And you can't fake the shipment number. Thats the power of the system. The trusted third party will in this case be the freight company in this case, since this is the only who can verify that a parcel has been sent. And almost 99% of shipment companies has a website where you can input a parcel number and find out if it has been shipped or not.

Fake sites like those people setting up phishing sites that looks like some freight company's site will of course be spotted and voted down.

I think its better to have the network vote about it instead.
So either the sender gets the cash back or the receiver gets the cash. Like a "real" escrow.

I wrote a thread about it: http://bitcointalk.org/index.php?topic=4856.0

Then its not possible to use the money as a "threat tool" either:
For example:

A sells a laptop without power adapter because A needs the power adapter to a new laptop.
B buys this laptop and in the business deal, its specific that power adapter is NOT included.
B then says "If you dont send the power adapter I will never release the money."

Now B is forced to send a power adapter to get the money for the laptop at all.
B will still lose the money even if A don't send any power adapter, but he still can force many extras from the seller for same money. And in this way fraud the seller.


With my solution with secure chargeback, it will never happen. B buys something from A. A sends the freight number as a reply to the transaction. If B now protest, everyone will be able to check at the freight'ers website that the parcel has really been sent and vote the transaction to A's favor. If the weight of the package seem illocigal, like a laser printer that weights 0,1 g, of course people will vote the transaction to B's favor.

Im not saying NATs are supposed to be firewalls/security devices.
I say that the "firewall feature" in a NAT is just a bonus, that have come extremely useful.

How many dedicated hardware firewalls are sold at today's consumer hardware stores? Its zero, sometimes a store *might* sell one brand of hardware firewall. Thats because NATs provide enough protection, so hardware firewalls sells extremely bad at a consumer store.

And firewalls are really necessary. Try connecting a PC to the internet, without NAT, without firewall, without any protection ever. You will see that the PC gets "owned" in the matter of minutes if not under just one hour, even if you dont touch the PC. All those worms out of the internet are scanning and attacking random IPs without any specific "targeting".

A NAT just drops these attacks so they will never reach the PC. You have to deliberately surf into a infected site or download/accept a infected file to get infected.


I just dont understand, why use UPnP at all? Whats the problem of the end user surfing to their router administration page and opening up 8333 for their bitcoin client? Its a simple and straightforward process of opening a incoming port in a router.

Luke-Jr: So you are saying that computers "are supposed" to be exposed to the internet with all these worms and such auto-infecting any computer it stumbles upon by attacking random IP adresses?

In the past, the security of NAT was really not necessary, but in the today era, NAT is a essential security that provides inbound protection. Without a NAT or some sort of firewall before a computer, the computer would pretty much get totally owned in about 15 minuters of connection of to the internet, even if you are not touching the computer.

Even router packaging advertises the natural NAT firewall function by a picture of a large padlock with the word "firewall" under it.

I think a UPnP function could be there, but make sure its OFF by default. Or even better, dont have any UPnP function at all, and the end user has simply to do port forwarding manually, its not rocket science to go to http://192.168.0.1 (or whats applicable for their router) and do port forwarding of 8333 to their computer's IP adress. Then we keep code amount and possible exploit vectors at a minimum.

I wish that the stupid idea "UPnP" never got invented at all.


Yes! I know that NAT was not intended* to be a firewall from the beginning, its just a positive "bi effect" from NAT:ing multiple computers together since the NAT does not know where to send unsolicited traffic. Its not a "bug" that you call it in other threads. Call it a positive effect.

If you dont want that effect, you can always put a PC in the DMZ zone of the router. But then, if you do that, prepare for that PC to be owned by every active worm out there on the internet circulating. And then that worm will spread to all other PCs in your network since its only a switch on the LAN side of the NAT.


* At the time where NATs where invented, firewalls wasn't really necessary, the virus/worm population on the internet was relatively low. So thats why the NATs where not intended to act as firewalls. It just come as a useful feature later when virus/worm population on internet got a little too high.

Voted "Off by default".

Reason: Since UPnP is something which can open incoming holes in a firewall, I think it should be off by default, and IF some user, which knows the consequences of enabling it, can enable it.

The reason is that Bitcoin in a such case will be very responsible for that computer's main security, if it has access to disable the firewall in a router (which UPnP is). For example, lets say there comes a exploit that allows someone to send a specifically crafted packet to bitcoin client on port 8333, and cause the bitcoin client to push out a UPnP packet opening arbiritary ports on the router. Dont give bitcoin too much abilities by default.

Also have safeguards in place that makes sure bitcoin CANNOT send out UPnP packets if its disabled in the interface. In other words, check in many places that UPnP is enabled before allowing a UPnP through, in many places, so even if a hacker manage to bypass a UPnP check via a exploit, there will be numerous other checks that needs to be bypassed too.

Read more here about the security consequences of UPnP:
http://www.grc.com/sn/sn-003.htm

And more here about how good security devices NAT:es are:
http://www.grc.com/nat/nat.htm

I have a little idea, I really don't know if this would be a good idea, but just discuss it.

The scheme would work like this:

You can elect to create either a standard non-reversible transaction, or you could create a secure reversible transaction.

A secure reversible transaction works in that way that you attach a note in the transaction, with a brief description of whats expected for return in the transaction, and all data that is needed to verify (this must be in english). The receiver of the bitcoins has to reply to this description to be able to claim the coins. The receiver should then reply in english, and have to supply evidence of having delivered what being asked.

For example a tracking URL to a freight company that makes it possible to track physical goods, a screenshot of transferred funds via paypal, or other evidence that is relevant for the case.

All of this could be described in a help file and a small how-to on how to verify transactions once a user selects to partipicate in secure votes (see later)


The recipient can also reject the transaction, immediately refunding the funds and not publishing any secure transaction over the network, which also refunds the 10 BTC fee minus lets say a rejected secure transaction fee of 1 BTC.

If the recipient ACCEPTS a transaction and affix evidence, the sender can select to ignore this, and then funds are released after a number of blocks (that correspond to 48 hours or something like that), or the sender can "protest" a transaction, for example if the recipient of the transaction tries to SCAM the sender.
If the sender ignores a transaction, the 10 BTC fee goes to the first whoever that calculates the block that releases this transaction.

Now "secure" transactions should have a huge fee (like 10 BTC or something like that). Now to the interesting part:

The bitcoin client should have a option "partipicate in secure transfer votes". If this is enabled, the user gets a popup OR some type of message in a inbox in the client as soon as a "secure transfer" appears on the network.
What all bitcoin users who have enabled "partipicate in secure transfer votes" does now, is to review the transaction as supposed from the sender of the bitcoins, and review the evidence published by the receiver of the transaction.

The user then votes that the transaction should either be chargebacked, or votes that the transaction should let go to the receiver. What the bitcoin client does now, is calculating blocks containing 1 YES or NO vote each containing the transaction, with "Proof Of Work"s and embeds this in the block chain. These blocks are always accepted once the required difficulty are set. (This means, more CPU power = more votes)

When the vote are over, the bitcoin network calculates number of votes for chargeback, and number of votes to release the coins and the majority wins. If theres a draw, the client will also include one extra block which are nearest after the vote expiration time.


The user can then configure how many percent of their total CPU capacity that should go to mining and how much should go to voting.

Now to the time part.
The user could have a specific time to accept/reject a secure transaction. This could be measured in blocks and could be 7 days or something like that and on timeout the transaction is REJECTed. When the user has accepted a transaction, there could be a specific time for voting, lets say 24 hours or something like that. When the vote is over, its tallied and then the network executes the specific action.
The sender could have 48 hours (2 days) to protest a transaction, before its immediately released without vote.


Now to where these 10 BTC in transaction fee should go where: When a vote is over, 10 BTC is divided along all votes that contributed to a specific "good" answer so the adress which casted a specific vote gets (1/X)*10 BTC where X is the total number of Y votes, where Y is the majority vote.


So lets say in a very small bitcoin network with 6 nodes, it works like this:

A = sender
B = receiver
C = random user who have elected for voting
D = random user who have elected for voting
E = random user who have elected for voting
F = random user who have NOT elected for voting.

A sends a "secure transfer" to B with 110 BTC containing a note like this: "100 BTC for a nokia 3310 + 10BTC shipping".

B have 2 choices. If B now REJECTS the transaction, its refunded to "A" minus a 1BTC fee to whoever calculates the block of refund.
If B now ACCEPT the transaction, and affixes a evidence, like this: "Yes, have sent the nokia 3310 now. Here is the tracking: http://www.large-freight-company.invalid/track.php?id=78563495495630247259"

A now gets the transaction in return. The A can now check if he deems the evidence legit, then he just does nothing (or immidiately releases funds) and the coins will be released to the sender, 10 BTC goes to whoever calculates the release block first. Or A can think "this looks like fraud" and click on PROTEST.

On PROTEST, this happens:
The bitcoin system now sends out the transaction for voting and affixes it a coutdown of 24 hours.
Now user C, D and E will get a message in the bitcoin client (in some form of inbox) or a popup with the vote. F does not get anything since he has not elected for voting.

The user C, D and E now checks the evidence and makes a decision if he deems the evidence legit.

Lets say C and D votes for the transaction to go to B, and E votes for the transaction to go to A.

The C and D client will now generate blocks containing "B votes" and push to the network, and E will generate blocks contatining "A votes" and push to the network.
In the end run, 100 blocks containing B votes goes out, and 25 blocks containing A votes goes out. B also gets the transaction. (eg the coins are released and NOT chargebacked)
C calculates 75 B votes, and D calculated 25 B votes.
Now C gets 10 BTC / 100, * 75 = 7,5 BTC in his account for his votes.
And D gets 10 BTC / 100, * 25 = 2,5 BTC in his account for his votes.
E does not get anything since he "voted wrong", which means the network rewards users for voting "right".

The network rejects any votes that are for expired polls or does not contain enough PoW.

This would give a new opportinity to earn BTC, and also helping the network to prevent scams, in this way allowing the network to decide about secure chargebacks.

The voting by "noobs" (which would mostly contain erronous votes) would get outclassed by those having large mining banks which could set their mining banks to only send out votes.

Also to prevent "noobs" from voting incorrectly, there could even be a fee for each vote sent out on 0,01 BTC. That fee you *always* get back along with the reward if you vote right (right as in voting like the majority). If you vote wrong (wrong as in voting like the minority), your 0,01 BTC fee will be lost and put in the pot that is divided along all winning votes. That would make a strong incentive to vote right.

Any thoughts?

[mike]: That is in *addition* to CCTV and anti-theft tags. Just because the shoplifters become "smart" and "bypass/disable" such countermeasures.


What I talk about, when talking about smart cards, is that it could be a optional feature. So smart phones could be the "standard" way of doing it, but for some people the smart card might be the way to go.

Maybe even RFID/NFC cards, but they rarely support Public-key cryptography. Then the *store* only needs a phone belongning to the store to do the actual transaction.



I think we should NOT support EV certificates because of the "monopoly" situation that arises out of EV certificates. Also the problem is that EV certificates require a high level of business with a good credit score and such, you cannot get a EV certificate on a "single-indivual business", which is the smallest form of business you can start.

The problem is that people might start to un-trust businesses which does not have a EV if this possibly is arisen.


The possible to do transactions should be equal for everyone. A simpler approach could be a bitcoin format for DNS. So the shop in question just publishes in their DNS record, a TXT containing like "bitcoin=" and their bitcoin adress. To verify the store in question, you type in a verify field "www.shopname.com" and then *the phone* does a DNS lookup and if the verification pass, it will show "Bitcoin adress OK".

Mike: Why require EV certificates? They are VERY expensive, and pretty unavailable for those in countries that does not have any available EV certified CA since the EV certification requires in-person validation.

A simpler approach is then that the store have a sign or label at the cash register that contains something that you can verify on your phone, and that is not easly replaceable. That would prevent a corrupt clerk from stealing the store's money to their own wallet.

A simple approach could be a color image created from the bitcoin adress. The color image is posted at the cash register in a tamper resistant fashion, and you simple check that the image that comes up on your phone just looks like the image at the cash register.



But the problem is that not everyone has smartphones, and some stores might not want you to take in your smartphone. There must be a way to use bitcoins in-store without a smartphone. Something that is "natural" to take inside a store without any suspicios looks and such. A smartcard is like a debit card, so it must be sufficently secure.

For example, in *some* electronic stores in sweden, expensive electronics and such are forbidden to take inside if you dont have a receipt on the original purchase, else they have a lawful right to confiscate the phone in question and do a police report on shoplifting/theft (since you can't prove that the phone you have belongs to you and not the store).
I have to leave my phone in the locker outside the store for example, before going in.

For example, you could charge your bitcoin smartcard with a little amount, and then the clerk cannot
transact more than you have on your card loaded. I do it with my VISA card, just charge it a little so if someone skims the card or do malicious transactions
I will not lose more than I have on my card.

With bitcoin cards, you could even charge multiple cards, with different sums. So you could have a card with 500BTC, one card with 100BTC, one card with 50BTC
and one card with 25BTC and one 10BTC card. Then the clerk cannot do a malicious transaction on the card.

If you are gonna buy for lets say for 55 BTC, you just use your 100BTC card.

I got a suggestion for a bitcoin in-store-transactions. The only changes that are required are support for smart cards in bitcoin client, and the possible to do PKCS#12 smart card cryptography and then send out the result of this on the bitcoin network.

This could work in this way:

You have 2 bitcoin adresses.
One, we can call "primary" and the second one "card" adress.

The "card" adress has its private and public keys stored on a smartcard, along with its wallet.dat (wallet.dat needs some compression/formatting to fit a smart card?).
The private key is stored on the smart card in a way that makes its extraction impossible, eg you can only "use" the key on the card, not see it or extract it.

The "card" adress also has everything, private, public and wallet backuped on the same PC as the "primary".

-----

What you do, is to send coins from your primary to your card adress, and then Bitcoin needs a function to transfer the actual coin files to the smart card.

You go to a store and should purchase a package of milk. Then you insert your bitcoin card into the store's reader that is connected to their cash system with a bitcoin client. If its PIN protected, you have to enter your PIN to unlock your smartcard.

Then the Store's bitcoin client calculates the signature on your coins using the smart card's PKCS#12 RSA functions, and then send out a transaction on the bitcoin network cointaining the purchase amount. The store waits until they get some confirmations, and then lets you leave with the milk.

The important is that the store cannot read or see the private key in any way, since then they would be able to "rob" you after you have left with your smartcard.


Blocking of a lost smartcard, is achieved by having the 2 adresses. Since you have a backup of the "card" wallet in your PC, the only thing that needs to be done, is to move all coins left (unspent) on the "card" adress to the "primary" adress, and then the card has 0 coins on it and is unuseable.


This would make a decentralized "card" system like mastercard/visa but completely decentralized.
To make this work, the bitcoin must support smart card readers, and have a possible to have API so when a smartcard is inserted you can do transactions from/to this smart card. The API could be used by everything, like "self checkout lanes", to vending machines, to stores who want to connect it with their regular cashregister system.
The bitcoin client could also have a interface to interact with a smart card and reader, so when you insert a smart card in a connected reader which contans a bitcoin wallet, there could be options to debit or credit the smart card. This would be good for small entities or indiviuals who want to do some affairs IRL with somone.


The good thing is that the system is robbery safe, not even the clerks cannot steal cash from the store since if the store does it right, they have a server in a unaccessible location which have all bitcoins. Since the bitcoin client in the cash computer only does a transaction from the "card" adress using the private key on the smart card, the only thing the clerk have "access" to is a specific smart card.
To prevent from night robberies, the store only needs to "truecrypt" the main server/wallet and a store manager has to enter the password everytime the store opens on the day.