I feel like a good deal of payment processors and merchants go by the route wherein the payment processor instantly converts the BTC to USD before paying the user.
This then eliminates the benefit of trustlessness anyways.
I guess if you assume merchants that are looking for payment methods wherein they keep the Bitcoin in the end, the trustless nature can "kinda" help. But if you already don't trust the payment processor, it seems like you would just set up your own system, especially if you're just having to listen to a single address, and not needing instant USD conversions as well.
(And as others have noted, the fee does not really add up when you consider the existence of bulk transactions)
Topic: Unique BTC amount instead of an address for IPN (Read 207 times)
The OP is in danger of thinking for himself too much and this dangerous criminal
should be reported to the police.
Reducing fees paid to miners will only do them out of a wage and think of the starving kids
Lets charge fees on bits instead of bytes because it sound much better along side the name
Bitcoin don't you think.
Bitcoin was never P2P banking but they are trying to sell it as that but even if I my wallet was connected to yours without
doing broadcasts and we managed to swap ownership somehow then they have us beat with the block-chain
Cleaver they are and all the mistakes so far could well be deliberate but every dog has it's day so maybe we can
cut the middleman out (Lightning banker network) and find the weak point
if we don't stop these criminals then someone will come up with a coin in a new ICO that is designed to
short Bitcoins price but forget you heard it from me
or that you would had made a fortune in the
last month.
should be reported to the police.
Reducing fees paid to miners will only do them out of a wage and think of the starving kids
Lets charge fees on bits instead of bytes because it sound much better along side the name
Bitcoin don't you think.
Quote
With the example above, a fee is only paid once, and the funds are transferred straight to the merchant which means that in all stages, either the customer or the merchant own the funds - never the IPN provider - a P2P IPN.
Bitcoin was never P2P banking but they are trying to sell it as that but even if I my wallet was connected to yours without
doing broadcasts and we managed to swap ownership somehow then they have us beat with the block-chain
Cleaver they are and all the mistakes so far could well be deliberate but every dog has it's day so maybe we can
cut the middleman out (Lightning banker network) and find the weak point
if we don't stop these criminals then someone will come up with a coin in a new ICO that is designed to
short Bitcoins price but forget you heard it from me
or that you would had made a fortune in the last month.
Thank you for your inputs! Would love to hear more 
One problem I see is that if a lot of people are buying stuff at the same price, there may not be enough unique numbers that can be generated that have a negligible effect on the amount that the customer is actually paying.
The issue that I see here, is that a fee is paid twice. Once from the end-user to the IPN provider's unique BTC address, and again from the IPN provider to the merchant's wallet address.
In the simplistic implementation a fee is paid three times: Once by the customer, once to move to the merchants wallet, and once more by the merchant when moving the funds to an exchange (or aggregating into a storage wallet.) Your idea drops that to two fees.
But there's simple optimization (without unique payment amounts): The payment processor can wait for a day/week/month/hour and aggregate all payments in one transaction to the merchants wallet. That's two fees per payment, plus only one fee to move the bulk payment further. Thus, your idea doesn't gain much.
Actually, if the merchant provides the payment processor their xpub key, then the processor can direct all customer payments directly to an address controlled by the merchant. Thus, there are no extra fees. (This does create the issue of how the the processor gets paid. They can no longer take a cut from every transaction. But they could bill monthly.)
BTW There are two ways to embed a unique amount in a transaction: The amount paid, and the miner's fee. Both can be adjusted by a few satoshis.
Most Bitcoin IPN providers work in the following way:
1. Merchant submits invoice information (i.e. amount, their btc address, user ID and unique invoice ID).
2. The IPN provider inserts this information to a DB and generates a unique btc address for this specific invoice.
3. The merchant receives the unique btc address from the IPN provider and presents it to the end-user.
4. Once the end user pays the agreed upon amount and the transaction receives enough confirmations, the IPN provider submits a notification (i.e. POST request) and sends the funds to the merchant's wallet address.
The issue that I see here, is that a fee is paid twice. Once from the end-user to the IPN provider's unique BTC address, and again from the IPN provider to the merchant's wallet address.
I was thinking about a different approach, where the end-user sends the funds to the merchant's wallet, and the IPN provider "listens" to the BTC address. In this case the invoice identifier would be the BTC amount instead of the btc address. For example:
1. Merchant creates a new invoice for 0.001 BTC, and submits its wallet address along with the invoice information to the IPN provider.
2. The IPN provider "generates" a unique number for that specific invoice, which should be very close to the original amount (i.e. 0.00100052 - a "gap" of 1 cent). The IPN provider inserts the data (with the new amount) to its database and starts "listening" to the merchant's wallet address.
3. Once the IPN providers spots a transaction for that particular amount (0.00100052 in our example), it flags the invoice as completed and informs the merchant.
With the example above, a fee is only paid once, and the funds are transferred straight to the merchant which means that in all stages, either the customer or the merchant own the funds - never the IPN provider - a P2P IPN.
What could be the cons of this method?
1. Merchant submits invoice information (i.e. amount, their btc address, user ID and unique invoice ID).
2. The IPN provider inserts this information to a DB and generates a unique btc address for this specific invoice.
3. The merchant receives the unique btc address from the IPN provider and presents it to the end-user.
4. Once the end user pays the agreed upon amount and the transaction receives enough confirmations, the IPN provider submits a notification (i.e. POST request) and sends the funds to the merchant's wallet address.
The issue that I see here, is that a fee is paid twice. Once from the end-user to the IPN provider's unique BTC address, and again from the IPN provider to the merchant's wallet address.
I was thinking about a different approach, where the end-user sends the funds to the merchant's wallet, and the IPN provider "listens" to the BTC address. In this case the invoice identifier would be the BTC amount instead of the btc address. For example:
1. Merchant creates a new invoice for 0.001 BTC, and submits its wallet address along with the invoice information to the IPN provider.
2. The IPN provider "generates" a unique number for that specific invoice, which should be very close to the original amount (i.e. 0.00100052 - a "gap" of 1 cent). The IPN provider inserts the data (with the new amount) to its database and starts "listening" to the merchant's wallet address.
3. Once the IPN providers spots a transaction for that particular amount (0.00100052 in our example), it flags the invoice as completed and informs the merchant.
With the example above, a fee is only paid once, and the funds are transferred straight to the merchant which means that in all stages, either the customer or the merchant own the funds - never the IPN provider - a P2P IPN.
What could be the cons of this method?
Jump to: