you guys may be right, but i don't really see it. why just give the money to a payment processor.
additional step to getting funds
could have some security implications
more costly, it could be cheaper to buy one of them php enabled vps a month if you get enough transactions. secuity is not an issue because the coins would only be on there for a short while.
It might be hard to imagine now because there is only 1, maby 2 stable bitcoin wallet manager things.(GUIs to not count because we need a pure php solution or similar, java could work, but php would be best because pretty much all providers have it)
Topic: Fast Transaction Solution (Read 2481 times)
Or VISA/MC get into the business of selling pre-paid credit cards for bitcoins, merchants don't have to change anything and everyone is happy.
is the customer giving the money to the payment processor?
For many merchants that would be best, except possibly in the case where the customer's choice of currency to pay with happens to correspond with the currency the merchant wishes to be paid with.
In all the other cases, that is, in any case where the currency the customer wants to pay with is not the same currency as the one the merchant wishes to be paid with, most small merchants who are not forex players would probably prefer that the customer pay the payment processor the not-what-the-merchant-actually-wants currency and the payment processor pays the merchant the currency the merchant does actually want.
-MarkM-
is the customer giving the money to the payment processor?
No, it's the merchant that pays - after all it's the merchant that wants the guaranteed payment. If this ends up costing half of 1% of the transaction cost then the merchant either eats the cost or ups all bitcoin prices by half of 1% (not dissimilar to the way some merchants charge extra for processing credit cards).
Of did I misunderstand the question? Maybe I did.
The money goes from the customer to the merchant. However the merchant's POS system is connected to the bitcoin network and the payment processor's computers (which are just part of the bitcoin network). The payment processor doesn't touch the money - they are told of the transaction and watch for double-spend for a couple of seconds before returning an OK signal to the POS machine. As part of the payment processor covering their own arse against double spends on "their" network, they send this particular payment all over the bitcoin network.
I'm sure someone could do some numbers and work out the probabilities of double spends vs time, based on how distributed a particular half of the double spend is distributed across the network. Those figures would determine how much the processor needs to charge to insure against double spends.
Also remember that if you want to double spend against the RodylandBitcoinPaymentGuarantee System, you need to ensure that one half of the double spend is on a part of the network that isn't readily reached by the nodes owned by this system. And the more isolated the node with the double spend, the less likely that transaction will be accepted by the network...
And if the RodylandBitcoinPaymentGuarantee System and the BitcoinGuaranteeByCtoon6 System decide to share transactions aggressively, that makes double spends even harder....
I don't know if anyone else has this though - I can't be the only one....
Is it that hard to imagine someone setting up a bitcoin processing guarantee service, maybe even as a part of a bitcoin POS solution. The service provider would have a pool of mining power combined with some well-distributed (network topography as well as geographically) bitcoin nodes.
The service provider would aggressively distribute their transactions to the network, as well as watch the network for "suspicious traffic", and give the merchant a red/green light on any given transaction within seconds - less time it currently takes someone to enter their PIN or sign a credit card slip, for example.
The service provider would also guarantee the transaction, in return for a transaction fee above-and-beyond the normal bitcoin transaction fee. Maybe the merchant can choose how long they want to wait, the longer the wait (30 seconds instead of 3 seconds?) the less the fee. Maybe the service provider strikes up a deal with some of the larger mining pools to always take their transactions (even fee-free ones) in return for a slice of the service fee in the event of the pool solving the block.
This provides the merchant with the certainty and speed they need, at a reasonable price compared to the price of processing credit card transactions.
That's just one idea, maybe other people have different ideas...
Is it that hard to imagine someone setting up a bitcoin processing guarantee service, maybe even as a part of a bitcoin POS solution. The service provider would have a pool of mining power combined with some well-distributed (network topography as well as geographically) bitcoin nodes.
The service provider would aggressively distribute their transactions to the network, as well as watch the network for "suspicious traffic", and give the merchant a red/green light on any given transaction within seconds - less time it currently takes someone to enter their PIN or sign a credit card slip, for example.
The service provider would also guarantee the transaction, in return for a transaction fee above-and-beyond the normal bitcoin transaction fee. Maybe the merchant can choose how long they want to wait, the longer the wait (30 seconds instead of 3 seconds?) the less the fee. Maybe the service provider strikes up a deal with some of the larger mining pools to always take their transactions (even fee-free ones) in return for a slice of the service fee in the event of the pool solving the block.
This provides the merchant with the certainty and speed they need, at a reasonable price compared to the price of processing credit card transactions.
That's just one idea, maybe other people have different ideas...
is the customer giving the money to the payment processor?
I don't know if anyone else has this though - I can't be the only one....
Is it that hard to imagine someone setting up a bitcoin processing guarantee service, maybe even as a part of a bitcoin POS solution. The service provider would have a pool of mining power combined with some well-distributed (network topography as well as geographically) bitcoin nodes.
The service provider would aggressively distribute their transactions to the network, as well as watch the network for "suspicious traffic", and give the merchant a red/green light on any given transaction within seconds - less time it currently takes someone to enter their PIN or sign a credit card slip, for example.
The service provider would also guarantee the transaction, in return for a transaction fee above-and-beyond the normal bitcoin transaction fee. Maybe the merchant can choose how long they want to wait, the longer the wait (30 seconds instead of 3 seconds?) the less the fee. Maybe the service provider strikes up a deal with some of the larger mining pools to always take their transactions (even fee-free ones) in return for a slice of the service fee in the event of the pool solving the block.
This provides the merchant with the certainty and speed they need, at a reasonable price compared to the price of processing credit card transactions.
That's just one idea, maybe other people have different ideas...
Is it that hard to imagine someone setting up a bitcoin processing guarantee service, maybe even as a part of a bitcoin POS solution. The service provider would have a pool of mining power combined with some well-distributed (network topography as well as geographically) bitcoin nodes.
The service provider would aggressively distribute their transactions to the network, as well as watch the network for "suspicious traffic", and give the merchant a red/green light on any given transaction within seconds - less time it currently takes someone to enter their PIN or sign a credit card slip, for example.
The service provider would also guarantee the transaction, in return for a transaction fee above-and-beyond the normal bitcoin transaction fee. Maybe the merchant can choose how long they want to wait, the longer the wait (30 seconds instead of 3 seconds?) the less the fee. Maybe the service provider strikes up a deal with some of the larger mining pools to always take their transactions (even fee-free ones) in return for a slice of the service fee in the event of the pool solving the block.
This provides the merchant with the certainty and speed they need, at a reasonable price compared to the price of processing credit card transactions.
That's just one idea, maybe other people have different ideas...
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.
But you just described the race attack! Again, all you have to do is watch the network for a few seconds, as already stated, to see that the coins that were supposedly sent to you were also apparently sent to someone else.
i misread your post, you can not watch the network for already existing transactions and always be 100% sure. as the network grows in size it may have unpredictable effects. sure right now you can check easily, but who knows. the store could be compromised over time by an attacker having a bunch of nodes that broadcast normal transactions, but refuses to broadcast ones not in its favor. botnets serve this purpose well and could be rented out for yet another purpose.
Are you just thinking out loud (so to speak)?
i guess, but you can not know for sure what the future will be. super peers would definitely reduce transaction latency, so it may not be a problem, you can always take gnutella as an example though, as it is very similar.
OK. Well, I recommend giving it more thought. For instance, in this scenario the attack requires that both transactions be broadcast, but that the merchant sees one transaction first and the miners see the other transaction first. Refusing to relay doesn't help this attack succeed unless you've somehow successfully separated the merchant from the rest of the bitcoin network. That's where you need not only a botnet, but a lot of luck. How are you going to prevent the merchant's bitcoind from connecting to a bitcoind not in your control, and then seeing what you're up to? If you don't have an "Internet kill switch" then this will be very hard to do. And by this time you've spent far more money than you can rip off Wal-Mart for at the register. Plus, they'll likely figure it out before you get to the parking lot.
and another factor to consider is volume. right now i estimate we are only seeing less than 1% at most. its probably below .1% of the amount if bitcoin takes off mainstream and is used as real currency. at this point i could see it being more burdensome to propagate all of them, and thus it would be slower. and i would also guess there would be less nodes with ports forwarded too. so sending more data with less nodes could be a problem, not only for race attacks, but the network in general.
yes all them numbers are pulled outa my ass, but id guess they are fairly optimistic.
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.
But you just described the race attack! Again, all you have to do is watch the network for a few seconds, as already stated, to see that the coins that were supposedly sent to you were also apparently sent to someone else.
i misread your post, you can not watch the network for already existing transactions and always be 100% sure. as the network grows in size it may have unpredictable effects. sure right now you can check easily, but who knows. the store could be compromised over time by an attacker having a bunch of nodes that broadcast normal transactions, but refuses to broadcast ones not in its favor. botnets serve this purpose well and could be rented out for yet another purpose.
Are you just thinking out loud (so to speak)?
i guess, but you can not know for sure what the future will be. super peers would definitely reduce transaction latency, so it may not be a problem, you can always take gnutella as an example though, as it is very similar.
OK. Well, I recommend giving it more thought. For instance, in this scenario the attack requires that both transactions be broadcast, but that the merchant sees one transaction first and the miners see the other transaction first. Refusing to relay doesn't help this attack succeed unless you've somehow successfully separated the merchant from the rest of the bitcoin network. That's where you need not only a botnet, but a lot of luck. How are you going to prevent the merchant's bitcoind from connecting to a bitcoind not in your control, and then seeing what you're up to? If you don't have an "Internet kill switch" then this will be very hard to do. And by this time you've spent far more money than you can rip off Wal-Mart for at the register. Plus, they'll likely figure it out before you get to the parking lot.
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.
But you just described the race attack! Again, all you have to do is watch the network for a few seconds, as already stated, to see that the coins that were supposedly sent to you were also apparently sent to someone else.
i misread your post, you can not watch the network for already existing transactions and always be 100% sure. as the network grows in size it may have unpredictable effects. sure right now you can check easily, but who knows. the store could be compromised over time by an attacker having a bunch of nodes that broadcast normal transactions, but refuses to broadcast ones not in its favor. botnets serve this purpose well and could be rented out for yet another purpose.
Are you just thinking out loud (so to speak)?
i guess, but you can not know for sure what the future will be. super peers would definitely reduce transaction latency, so it may not be a problem, you can always take gnutella as an example though, as it is very similar.
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.
But you just described the race attack! Again, all you have to do is watch the network for a few seconds, as already stated, to see that the coins that were supposedly sent to you were also apparently sent to someone else.
i misread your post, you can not watch the network for already existing transactions and always be 100% sure. as the network grows in size it may have unpredictable effects. sure right now you can check easily, but who knows. the store could be compromised over time by an attacker having a bunch of nodes that broadcast normal transactions, but refuses to broadcast ones not in its favor. botnets serve this purpose well and could be rented out for yet another purpose.
Are you just thinking out loud (so to speak)?
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.
But you just described the race attack! Again, all you have to do is watch the network for a few seconds, as already stated, to see that the coins that were supposedly sent to you were also apparently sent to someone else.
i misread your post, you can not watch the network for already existing transactions and always be 100% sure. as the network grows in size it may have unpredictable effects. sure right now you can check easily, but who knows. the store could be compromised over time by an attacker having a bunch of nodes that broadcast normal transactions, but refuses to broadcast ones not in its favor. botnets serve this purpose well and could be rented out for yet another purpose.
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.
But you just described the race attack! Again, all you have to do is watch the network for a few seconds, as already stated, to see that the coins that were supposedly sent to you were also apparently sent to someone else.
i think you guys are missing the point. this is not really for online stuff
Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.
yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.
Why should I go to all this trouble when I could just spend bitcoins in the shop?
you can, but it does not provide any real security for the shop, and the shop may not even accept them without waiting for a block. this is the solution to the problem where you don't want to wait 10 minutes or more for your stuff, and provide security for the shop against double spending.
I see the system to be very fair, shops should not have to just accept 0 block transactions.
The shop doesn't need to wait for a block if you are paying in person.
why not, if they just accept unverified transactions they are asking to get ripped off.
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.
Or maybe we phase out POS purchases completely...
yeah, why dont you go buy a watermelon on ebay and see how that turns out.
Or maybe we phase out POS purchases completely...
i think you guys are missing the point. this is not really for online stuff
Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.
yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.
Why should I go to all this trouble when I could just spend bitcoins in the shop?
you can, but it does not provide any real security for the shop, and the shop may not even accept them without waiting for a block. this is the solution to the problem where you don't want to wait 10 minutes or more for your stuff, and provide security for the shop against double spending.
I see the system to be very fair, shops should not have to just accept 0 block transactions.
The shop doesn't need to wait for a block if you are paying in person.
why not, if they just accept unverified transactions they are asking to get ripped off.
This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.
i think you guys are missing the point. this is not really for online stuff
Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.
yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.
Why should I go to all this trouble when I could just spend bitcoins in the shop?
you can, but it does not provide any real security for the shop, and the shop may not even accept them without waiting for a block. this is the solution to the problem where you don't want to wait 10 minutes or more for your stuff, and provide security for the shop against double spending.
I see the system to be very fair, shops should not have to just accept 0 block transactions.
The shop doesn't need to wait for a block if you are paying in person.
why not, if they just accept unverified transactions they are asking to get ripped off.
i think you guys are missing the point. this is not really for online stuff
Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.
yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.
Why should I go to all this trouble when I could just spend bitcoins in the shop?
you can, but it does not provide any real security for the shop, and the shop may not even accept them without waiting for a block. this is the solution to the problem where you don't want to wait 10 minutes or more for your stuff, and provide security for the shop against double spending.
I see the system to be very fair, shops should not have to just accept 0 block transactions.
The shop doesn't need to wait for a block if you are paying in person.
i think you guys are missing the point. this is not really for online stuff
Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.
yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.
Why should I go to all this trouble when I could just spend bitcoins in the shop?
you can, but it does not provide any real security for the shop, and the shop may not even accept them without waiting for a block. this is the solution to the problem where you don't want to wait 10 minutes or more for your stuff, and provide security for the shop against double spending.
I see the system to be very fair, shops should not have to just accept 0 block transactions.
i think you guys are missing the point. this is not really for online stuff
Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.
yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.
Why should I go to all this trouble when I could just spend bitcoins in the shop?
i think you guys are missing the point. this is not really for online stuff
Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.
yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.
Jump to: