Topic: [Feature Request] Add ability to append "satoshi codes" to transactions. (Read 2009 times)

This thread is not about transactions that have received 6 confirmations, so don't even bring that up as it only confuses the issue.

What we are talking about here is 0 confirmation transactions, and if you really trust 0 confirmation bitcoin transactions more than a credit card transaction, then your enthusiasm has definitely outrun your business sense.


And what are you going to do if someone shows you an ID and then double-spends anyway?  Are you really going to go through the trouble of trying to track them down and sue them?  Are you going to report it as a crime, an action that will with 100% certainty never get you your money back but maybe at least give you some personal satisfaction?  If you do, how would you ever prove that the customer double-spent?  The bitcoin address that was paid from is anonymous and cannot be tied definitively to the user.  Furthermore, the payment address paid to (via the double-spend) cannot be proven to not be yours either.

Accepting bitcoins with zero transactions is just about the same, from a vendor risk standpoint, of accepting cash that has a significant chance of being counterfeit, and without any way to assess whether the cash is counterfeit at the point of accepting the money.


Awesome.  Where are you located?  I like free computers.

No, I haven't.
Why don't you take the fingerprints of your customers? It is more secure than IDs.
Wasn't bitcoin supposed to be anonymous, just like paying with cash?

Let me guess, you've never run a business before. Well I do. I trust bitcoins 1440 times more than I trust credit cards, even 0/unconfirmed transactions. Any credit card transaction can be easily reversed up to 60 days later. A bitcoin transfer is nearly impossible to revoke 1 hr after receiving it.

The solution is simple, and it's already in place with credit cards. Haven't you been asked to show ID when using a credit card? Solution: Accept 0/unconfirmed transactions with a valid ID.

This isn't just rhetoric, I'm backing my words up with a real commitment, with real money and products on the line. You can walk into my store and buy a top-of-the-line computer and I'll let you walk out the door with it after seeing a 0/unconfirmed transaction on my bitcoin node and showing a valid ID. A credit card transaction is far more risky to me.

I think that's incredibly premature and pollutes the wiki space.  Numerous reasons have been pointed out here why this idea is better served by other mechanisms.  This "satoshi codes" idea will never make it into bitcoin and having it on the wiki before it's even an agreed-to concept is, like I said, premature and polluting.

Of course. You may wish to follow this thread as well:
https://bitcointalksearch.org/topic/a-proposal-for-fast-pos-transactions-with-bitcoin-28565

Merchants need to use different pubkeys per transaction for other reasons anyway, so there's no point supporting this. The problems Meze Grill has are just due to the immaturity of various mobile clients. Android users are nearly there, if BitCoinJ were more complete/less buggy and everyone used an Android phone you could transact in the manner Bitcoin was intended to be used without issue. The first problem will be solved with time. The second issue will always exist, but hopefully there'll be a solution for iPhone/WinMo users coming along at some point.

It's quite safe for a restaurant to accept zero-confirmation transactions, Satoshi himself said as much. You don't need to wait 30 seconds. If an attacker has to wait only a second or two behind the real transaction, he is very unlikely to win as the proper transaction spreads exponentially.

Good idea, but then the client needs to support this.

+1
The tool is here and works well, no need for messing with the amount

This sounds like the wrong way to go for me.

If there is a need for transaction identifiers beyond using a different address per usage, we should move to OP_DROP id's in transaction scripts or something similar, instead of hacking it inside the amount field.

At some point the big mining pools will provide a service to merchants. If the transaction carries a sufficient fee, the miners will certify that they have seen the transaction and that they will include it in the next block if they are the ones to generate that block.

That way, merchants can gain "good enough" assurance that the transaction they have seen is "the good one and not the double spend".

There is now a wiki entry about this:
https://en.bitcoin.it/wiki/Satoshi_codes

This assumes that if I send out my double-spend attempt immediately after the vendor has convinced themselves that no double-spend has been attempted so far, that my second transaction won't 'win'.  The chances of this happening are a function of both the amount of delay between my initial transaction going out and the vendor accepting it at face value, and the average delay of transactions propogating through the network.  I guess vendors could wait like 30 seconds (probably about as long as customers would tolerate waiting for their payment to be confirmed) and hope that this is enough of a "head start" for the first transaction to have a very, very high chance of beating any subsequent transactions into a block.

Also the vendor has to keep track of all outstanding transactions not yet in blocks to be sure that I didn't already spend the coin a few minutes before presenting the a transaction for the same coin to the vendor.  This would be incredibly costly for vendors when bitcoin is very big, and I guess they'd have to consolidate their costs into a single data center, or buy that service from someone they trust, both of which add to the cost of processing transactions.  Of course they wouldn't have to pay credit card fees either so that may be a wash.

I guess that's the only way I could see vendors trusting unconfirmed transactions; they could pay a third party to act as an insurer against double-spends.  That third party would be heavily connected into the bitcoin network to try to minimize their chance of a double-spend occurring that they would have to pay the insurance on, and they would set a transaction fee that the vendor would then either eat (and if it's as low or lower than credit card transaction fees this should not be a problem) or directly charge the customer (unlikely once bitcoin was well-accepted enough to be an expected form of payment, just like vendors don't typically charge extra for credit card payments (although some very low-margin vendors do)).

Once all of that infrastructure is in place, it makes little or no sense to have this satoshi code idea.  The customer would just submit their transaction to the vendor, who would submit it to the network and then ask their double-spend insurer to let them know when it can validate that the transaction is on the network and that it appears valid.  The insurer might have an implicit delay before they will answer in the affirmative to give the transaction time to get the 'head start' that they believe improves its chance of being accepted without being a double-spend.


Having an account implies trust between you and the account holder.  So far trust has not gone very far in the world of bitcoin.  The only thing you can really trust with bitcoin is the validated transactions 6 or so blocks back in the block chain.  Which is why the block chain exists and why trying to get around it kind of defeats the purpose of bitcoin ...

You have valid points, about someone being able to execute two transactions for every one transaction, hoping the vendor sees his own transaction first, and then the other nodes will solve a block with the other transaction.  I can see how this would be low-risk for the buyer.

Correct me if I'm wrong, but I believe this can be avoided, though I'm not familiar enough with the networking protocol to know if it will in fact work like this:
If enough nodes see one transaction first and enough other nodes see the other transaction first, then the vendor's node will actually see both conflicting transactions.  The client software is set up to simply reject the second transaction, but it could easily be set up to raise a red flag if it sees a threatening second transaction.  If the vendor doesn't see the second transaction, then not enough other nodes received it first to be a significant threat.  Sure, it can still happen, but you're dropping the frequency of success by one or two orders of magnitude here. 

Since the double-spend has to be executed immediately for any chance for this to attack to succeed, the vendor will also see the second transaction right away, and the vendor can choose to refuse service, call the police, etc.  Hell, half the time the transaction will go through anyway and they'll get the money even after they refused service.  If this actually works, that substantially reduces the probability of success, and also adds considerable risk to the buyer attempting this.


-Eto

P.S. - Of course, this can also be resolved with third-parties.  I wouldn't mind having a small quantity of money (5% of my BTC) in a third-party account that specifically guarantees immediate transaction validity, and linked to most major vendors for this purpose.

Nobody has any proof that the transaction will be included in 'the next block' just because the vendor has seen it on the network.  Nobody knows how the network will work when bitcoin is big enough to be used in point of sale.  It's quite possible that some transactions will never even make it to every miner, so I can easily send out two conflicting transactions and nobody could be certain that they, or any particular miner, would see both transactions, and could not prove which one would end up in the next block; or even if there will be a block chain fork resulting from my two transactions that take a few blocks to resolve.

I don't know why vendors will expose themselves to the risks of a system that everyone can attempt to game without any negative consequence to themselves since they are anonymous.  Everyone will just use clients that constantly try to double spend and get away with it; what's the harm in trying?  Every once in a while you'll get lucky and get free goods without any chance of being identified as the perpetrator of the fraud.

You may believe that the risk of chargebacks on credit cards are higher, but until this is proven in practice nobody will know for sure.

What do I think credit cards are?  They are a way for me to promise to pay a vendor, where that promise has some credibility because the credit card companies act to insure the validity of the transaction.  Back in the 1950s or whenever credit cards came along, you could have made the argument that credit cards were no more trustworthy than end users because they hadn't been proven yet and hadn't been established as a form of payment that vendors could trust.  But not anymore; vendors *know* that they can trust credit card transactions; they know who the credit card companies are and the credit card companies know who the customers are.  The vendors know that as long as they follow the credit card companies' rules, they will get paid; the cost to VISA of not being trustworthy to vendors would be way too high for VISA (it would take them out of a multi billion dollar market) and VISA knows that and vendors know that VISA knows that.

In short, vendors know they can trust credit cards.  They do *not* know they can trust anonymous random joe customer who can so easily game bitcoin to their advantage.

I am getting a little tired of explaining this because it keeps coming up over and over again in the forums.  So I'll be brief.  Quite simply, a vendor cannot trust an unconfirmed transaction because they cannot know if a double spend attempt for that transaction will succeed.  They can trust that such a double-spend has not been attempted if a) they believe that they know every transaction that has ever been attempted for the bitcoin in question, which requires that they see every, or almost every (enough to have confidence that very rarely will they not see a transaction) transaction that goes across the bitcoin network, which, once the bitcoin network is big enough that it's being used at point of sale (in theory, like I said that will never happen), is no small feat; and b) they *remember* every transaction for an indefinite amount of time to protect against double spends, which is no small feat once again in the hypothetical world where bitcoin is so big that it's being used at point of sale; and c) they have to believe that if you submit a double-spend attempt the second after they accept your unconfirmed transaction, that whoever solves the next block will have seen the first transaction first and the second transaction second, if at all, and will produce a block with the "valid" transaction in it instead of the "attempt to cheat the vendor" transaction.

That is alot of ifs.  If you really think vendors are going to trust such a system, well then, you are wrong, plain and simple.

Even if the chances of the transaction validation going the way of the vendor is very high, well, it is perfectly free for customers to always attempt the double spend since they are anonymous and it doesn't hurt them at all to try.  If they succeed 1% of the time, then that means that 1% of all of the transactions that the vendor accepts are going to leave them without the bitcoins they thought they got.  Will vendors trust a system where people can attempt to defraud them without any fear of any negative consequence whatsoever?  And can you convince vendors that the chance of this fraud succeeding is as low as 1% and not higher?  I don't think they will, and I don't think you can.

Unconfirmed transactions are many orders of magnitude safer than "taking someone's word for it."  The transaction wouldn't have propagated through the network if it wasn't valid, and it will be included in the next block regardless of whether the sender wants to revoke it.  If the seller can see the transaction on their screen, then it's currently not possible to reverse it without a multi-milllion dollar double-spend attack or something very creative. 

I believe, the risk of chargebacks on credit cards are much higher than the risk of an unconfirmed-but-valid transaction not eventually entering the blockchain.

What do you think credit cards are? Unconfirmed Bitcoin transactions are still several times less likely to fail after the customer has left than that. If you are trusting enough to take credit cards, you might as well take unconfirmed valid Bitcoin transactions as well.

First: bitcoin will never be used for point-of-sale transactions.  It requires a minimum of 30 minutes - 1 hour (depending on the vendor's level of paranoia) to verify transactions and such a payment delay will never work in a point-of-sale setting.  Lots of people propose ideas to try to get around this but they all require vendors to accept unvalidated transactions, which is equivalent to taking someone's word that they will pay, and if they're going to accept that level of trust (which no vendor will), then they might as well not request that you issue any kind of transaction at all at the point of sale and just allow you to leave with the promise to submit a transaction to the network at your convenience later.

Second: if a vendor ever were foolish enough to accept bitcoin at point-of-sale, and if they stayed in business long enough with all of the free goods they will end up giving out as a result, then I would expect that the easiest thing would be for the customer to submit a transaction to the vendor for the vendor to validate and then submit to the network on the customer's behalf.  This customer-vendor exchange would be enough to establish that the payment was from the customer for the specific service or good being paid for, and there would be no need for tags within the transaction itself.

You should know that all transaction are permanently stored in the network and everyone can view it. That means you are leaking some message of your transaction to the world. It can make some trouble for the official client if there is standard interpretation, maybe lawsuit, maybe force people out by some disgusting information. I am not sure. So, if you want to use this, it would be better to do it in a small circle.

The correct way to handle transaction is to generate a new public address and add the name like transaction#87 to it. A suggestion feature for your case should be the functionality to add tag to all transaction in your own client cos it is really lack currently.

If I understand it how it works correctly, if a transaction consists of multiple inputs and multiple outputs then a "satoshi code" embedded in the transaction fee would get lost, because there is no more 1:1 correlation anymore between from-addresses and to-addresses.

So you would have to either embed the satoshi code in the output amount (and accept having 'strange' amount numbers, bitcoin-processing software need to be fail-safe against these kind of transactions anyway) or make sure the client puts a transaction together with only one to-address.