To clarify the use case for instant transactions:
- the seller cannot cheat (or obviously not), i.e. it can be guarantied that the seller transfers the item immediately to the buyer after the buyer submits his transaction
- e.g. supermarket
In any other case, another type of transaction should be used: http://qubic.boards.net/thread/9/fighting-scam
Instant transaction would be too insecure to both the buyer and the seller.
Topic: [Nxt] Instant transactions with guaranteed confirmation (Read 8019 times)
need TF fully implemented,then instant transaction,right?
I still struggle with the notion of instant.
We need to give advice to merchants on how long they have to wait for double transactions.
We need to give advice to merchants on how long they have to wait for double transactions.
In my experience anything more than 10s is a problem.
So, let's hope that suffices.
I still struggle with the notion of instant.
We need to give advice to merchants on how long they have to wait for double transactions.
We need to give advice to merchants on how long they have to wait for double transactions.
In my experience anything more than 10s is a problem.
I still struggle with the notion of instant.
We need to give advice to merchants on how long they have to wait for double transactions.
We need to give advice to merchants on how long they have to wait for double transactions.
i see complexity in moving NXT between the normal account and the special account.
Also the chance to end up with money in the wrong account at the wrong time.
Could this be done by implementing a reserved balance?
So I reserve 10 or 20% of my balance for 'instant transactions', this reserved balance is not available for normal transactions
I can create instant transactions against my 'reserved balance'
NXT checks the total of instant transactions broadcast against the reserved balance
If instant transaction balance >= reserved balance then no more instant transactions will be allowed.
If any instant transactions are outstanding confirmation then the reserved balance cannot be released so this cannot be used for other normal transactions.
If a forger rejects the instant transaction then the instant balance of course reduced.
Attack - the instance balance is updated on broadcast so you would have to spam nodes which did not get the broadcast and know which these were .... every time there is a broadcast the instant balance is updated so there is a small race window where a spammer would have to outpace the networks ability to update the instant balance.
Also the chance to end up with money in the wrong account at the wrong time.
Could this be done by implementing a reserved balance?
So I reserve 10 or 20% of my balance for 'instant transactions', this reserved balance is not available for normal transactions
I can create instant transactions against my 'reserved balance'
NXT checks the total of instant transactions broadcast against the reserved balance
If instant transaction balance >= reserved balance then no more instant transactions will be allowed.
If any instant transactions are outstanding confirmation then the reserved balance cannot be released so this cannot be used for other normal transactions.
If a forger rejects the instant transaction then the instant balance of course reduced.
Attack - the instance balance is updated on broadcast so you would have to spam nodes which did not get the broadcast and know which these were .... every time there is a broadcast the instant balance is updated so there is a small race window where a spammer would have to outpace the networks ability to update the instant balance.
That idea would simplify things for user. Maybe not for CfB, but I could live with that.
However, you should know that you changed the original process.
A user should reserve part of his account for instant transactions. 1/10 of THESE reserved NXT can only be spend within the 24 hours timeframe.
This thread is dedicated to discussion of Nxt features (https://bitcointalksearch.org/topic/ann-nxt-descendant-of-bitcoin-303898), don't confuse it with Bitcoin or other altcoins.
In Bitcoin a payment is made by transferring all coins from input to output addresses with difference between input and output paid as transaction fee. If someone wants to send only part of the coins they must send the rest back to one of their own addresses. An attempt to use the same input twice is a double-spending, only one of the transactions will be confirmed even if enough money is sent back.
Unlike Bitcoin and its forks, Nxt uses a single account instead of multiple addresses for each user. It is possible to send multiple transactions from the same source address (called "account"), all these transactions will be confirmed if the account holds enough coins. Someone still can attempt a double-spending by paying for something with low fee and then sending all their coins to other account with higher fee, making it impossible to confirm the first payment.
We can counteract a double-spending attack in Nxt by using special accounts. A special account has certain limits that don't let to create transactions for more than (for example) 1/10th of the balance in total within a 24 hour timeframe. The network will simply ignore transactions and blocks that violate this rule.
A merchant (or a vending machine) can accept payments from special accounts without waiting for confirmations. The only thing should be done is checking that a received transaction doesn't violate the rule.
Does anybody see flaws or disadvantages in such design?
P.S. Payment privacy in Nxt will be provided via mixing.
In Bitcoin a payment is made by transferring all coins from input to output addresses with difference between input and output paid as transaction fee. If someone wants to send only part of the coins they must send the rest back to one of their own addresses. An attempt to use the same input twice is a double-spending, only one of the transactions will be confirmed even if enough money is sent back.
Unlike Bitcoin and its forks, Nxt uses a single account instead of multiple addresses for each user. It is possible to send multiple transactions from the same source address (called "account"), all these transactions will be confirmed if the account holds enough coins. Someone still can attempt a double-spending by paying for something with low fee and then sending all their coins to other account with higher fee, making it impossible to confirm the first payment.
We can counteract a double-spending attack in Nxt by using special accounts. A special account has certain limits that don't let to create transactions for more than (for example) 1/10th of the balance in total within a 24 hour timeframe. The network will simply ignore transactions and blocks that violate this rule.
A merchant (or a vending machine) can accept payments from special accounts without waiting for confirmations. The only thing should be done is checking that a received transaction doesn't violate the rule.
Does anybody see flaws or disadvantages in such design?
P.S. Payment privacy in Nxt will be provided via mixing.
One disadvantage I see is that people might be reluctant to do it because what happens if a crisis occurs? Ie: a major bug is found, the NXT economy collapses, Mt Gox scenario, etc. However, it might work for people's hot wallets ie: an account set up for "mad money" with only trivial amounts held there.
In that scenario I think it should be as easy o set up as possible ie: checking a box saying "designate this account as hot wallet" with a clear explanation of the implications posted and warning about putting large amounts there.
Iis there a way to simply have the client watch for double-spends until confirmations come in? I thought that's what the "double-spending transactions" servlet was going to be for when implemented.
Quote
P.S. Payment privacy in Nxt will be provided via mixing.
IMHO I think mixing stands a high chance of being made illegal in the future. Tread with caution.
i see complexity in moving NXT between the normal account and the special account.
Also the chance to end up with money in the wrong account at the wrong time.
Could this be done by implementing a reserved balance?
So I reserve 10 or 20% of my balance for 'instant transactions', this reserved balance is not available for normal transactions
I can create instant transactions against my 'reserved balance'
NXT checks the total of instant transactions broadcast against the reserved balance
If instant transaction balance >= reserved balance then no more instant transactions will be allowed.
If any instant transactions are outstanding confirmation then the reserved balance cannot be released so this cannot be used for other normal transactions.
If a forger rejects the instant transaction then the instant balance of course reduced.
Attack - the instance balance is updated on broadcast so you would have to spam nodes which did not get the broadcast and know which these were .... every time there is a broadcast the instant balance is updated so there is a small race window where a spammer would have to outpace the networks ability to update the instant balance.
Also the chance to end up with money in the wrong account at the wrong time.
Could this be done by implementing a reserved balance?
So I reserve 10 or 20% of my balance for 'instant transactions', this reserved balance is not available for normal transactions
I can create instant transactions against my 'reserved balance'
NXT checks the total of instant transactions broadcast against the reserved balance
If instant transaction balance >= reserved balance then no more instant transactions will be allowed.
If any instant transactions are outstanding confirmation then the reserved balance cannot be released so this cannot be used for other normal transactions.
If a forger rejects the instant transaction then the instant balance of course reduced.
Attack - the instance balance is updated on broadcast so you would have to spam nodes which did not get the broadcast and know which these were .... every time there is a broadcast the instant balance is updated so there is a small race window where a spammer would have to outpace the networks ability to update the instant balance.
What do you think about random lock times for transactions to make instant transactions safe?
If you have a random lock time for special accounts an attacker can't predict any more who will be the forger of the transaction. So an attacker could not attempt to doulbe spend by replacing the transaction with another.
The transaction would be immediately broadcasted to the Network, but have to wait a random time until added to the Blockchain
Example implementation:
Every forger adds an one random number (only 1 or 0) to his forged block on the Blockchain.
A transaction for these specific accounts can only be added to the Blockchain if the last 8 bits of hash of (the random numbers in the last 100 Blocks plus the accounts public key) are zero.
Advantage of this is that you can spend the entire account balance at once.
If you have a random lock time for special accounts an attacker can't predict any more who will be the forger of the transaction. So an attacker could not attempt to doulbe spend by replacing the transaction with another.
The transaction would be immediately broadcasted to the Network, but have to wait a random time until added to the Blockchain
Example implementation:
Every forger adds an one random number (only 1 or 0) to his forged block on the Blockchain.
A transaction for these specific accounts can only be added to the Blockchain if the last 8 bits of hash of (the random numbers in the last 100 Blocks plus the accounts public key) are zero.
Advantage of this is that you can spend the entire account balance at once.
Ok, my bad.. good idea!!
True.. but still I don't like that, maybe something like you can spend up to your entire balance but have to wait for n confirmations first or something?
Big transactions don't need to be instant but they need to be possible.. say someday I want to put down a down payment on the new condo I'm buying.. I want it to be possible to put 90% of my savings into this down payment, without splitting it into say 20 payments? Because first you'd be able to pay 10%, but then only 90% is left, so next would be 10% of 90%, which is 9%, then 8.1%, then 7.29%, etc. and it'd take a lot more than 9 payments to pay it off. Or am I missing something?
I don't see it as a huge problem, there are ways to work around it, but it does need to be possible to do somewhat easily. Right?
Big transactions don't need to be instant but they need to be possible.. say someday I want to put down a down payment on the new condo I'm buying.. I want it to be possible to put 90% of my savings into this down payment, without splitting it into say 20 payments? Because first you'd be able to pay 10%, but then only 90% is left, so next would be 10% of 90%, which is 9%, then 8.1%, then 7.29%, etc. and it'd take a lot more than 9 payments to pay it off. Or am I missing something?
I don't see it as a huge problem, there are ways to work around it, but it does need to be possible to do somewhat easily. Right?
I don't see a problem here. U r supposed to have 2 accounts, 1 for "slow" transactions without a limit and another for "instant" ones (like pocket money).
True.. but still I don't like that, maybe something like you can spend up to your entire balance but have to wait for n confirmations first or something?
Big transactions don't need to be instant but they need to be possible.. say someday I want to put down a down payment on the new condo I'm buying.. I want it to be possible to put 90% of my savings into this down payment, without splitting it into say 20 payments? Because first you'd be able to pay 10%, but then only 90% is left, so next would be 10% of 90%, which is 9%, then 8.1%, then 7.29%, etc. and it'd take a lot more than 9 payments to pay it off. Or am I missing something?
I don't see it as a huge problem, there are ways to work around it, but it does need to be possible to do somewhat easily. Right?
Big transactions don't need to be instant but they need to be possible.. say someday I want to put down a down payment on the new condo I'm buying.. I want it to be possible to put 90% of my savings into this down payment, without splitting it into say 20 payments? Because first you'd be able to pay 10%, but then only 90% is left, so next would be 10% of 90%, which is 9%, then 8.1%, then 7.29%, etc. and it'd take a lot more than 9 payments to pay it off. Or am I missing something?
I don't see it as a huge problem, there are ways to work around it, but it does need to be possible to do somewhat easily. Right?
So it is impossible to spend more than 1/10 of your balance at once? Meaning that if you would like to buy something that cost 10 NXT and you only have 25 in your account, it is impossible to buy it? That seems like a problem to me...
Our life is full of trade-offs...
So it is impossible to spend more than 1/10 of your balance at once? Meaning that if you would like to buy something that cost 10 NXT and you only have 25 in your account, it is impossible to buy it? That seems like a problem to me...
I guess point 1 takes the same propagation time than a normal transaction.
So this is not what I'm looking for if I'm in a hurry. Correct?
So this is not what I'm looking for if I'm in a hurry. Correct?
Incorrect. This is done once in advance.
Instant means not waiting at all.
Instant transactions will be implemented after the Messaging feature. That is how it will work:
1] You publish on the blockchain a message saying that your account becomes a special account.
2] You use the account for instant transactions.
3] At some point you decide to empty the account, so you publish a message saying that the account becomes an ordinary one.
4] Now you can't use instant transactions and have to wait for 1440 blocks (~24 hours) to withdraw all the coins.
You can send 1/10th of the balance a zillion times, but all the transactions except one of them won't be included into a block. The odds that a peer will see only 1 transaction are negligibly small, if a merchant notices other transactions that exceed the daily limit they will not sell you anything.
Instant transactions will be implemented after the Messaging feature. That is how it will work:
1] You publish on the blockchain a message saying that your account becomes a special account.
2] You use the account for instant transactions.
3] At some point you decide to empty the account, so you publish a message saying that the account becomes an ordinary one.
4] Now you can't use instant transactions and have to wait for 1440 blocks (~24 hours) to withdraw all the coins.
You can send 1/10th of the balance a zillion times, but all the transactions except one of them won't be included into a block. The odds that a peer will see only 1 transaction are negligibly small, if a merchant notices other transactions that exceed the daily limit they will not sell you anything.
I guess point 1 takes the same propagation time than a normal transaction.
So this is not what I'm looking for if I'm in a hurry. Correct?
it's not clear why...
if 2 * 1/10th are deducted then he violated the 1/10th per day rule... so one of the tx should have been ignored
also, if instead of buying one thing, he buys 19 things, and the merchants are not connected between them, 20 * 1/10th would be deducted. Except he only has 10/10ths. That's a double spend.
if 2 * 1/10th are deducted then he violated the 1/10th per day rule... so one of the tx should have been ignored
also, if instead of buying one thing, he buys 19 things, and the merchants are not connected between them, 20 * 1/10th would be deducted. Except he only has 10/10ths. That's a double spend.
Nothing bad will happen if someone spends more than 1/10th of the balance. The rule is set to avoid risk of spending more than 100% of coins.
Merchants don't need to be connected each other. They need to be connected to the network.
First of all noone can spend its balance twice, peers won't generate such blocks nor they accept them.
The goal of 1/10th rule is to protect merchants in situation when they don't see some transactions that can be confirmed and lead to cancellation a transaction accepted by a merchant. The goal is achieved by creating necessity to send at least 10 transactions before attempting a double-spending. If a merchant sees at least 1 of these transactions they can refuse to sell goods. Odds that all 10 transactions won't reach a particular merchant are negligibly small. The network helps to protect merchants by refusing to confirm transactions that violate the 1/10th rule. If someone sends 2 transactions (first to themselves and second to a merchant) the merchant will wait a little bit longer before getting the money if the first transaction is confirmed in the first place. This looks like a violation of the rule, but it's completely non-critical.
The goal of 1/10th rule is to protect merchants in situation when they don't see some transactions that can be confirmed and lead to cancellation a transaction accepted by a merchant. The goal is achieved by creating necessity to send at least 10 transactions before attempting a double-spending. If a merchant sees at least 1 of these transactions they can refuse to sell goods. Odds that all 10 transactions won't reach a particular merchant are negligibly small. The network helps to protect merchants by refusing to confirm transactions that violate the 1/10th rule. If someone sends 2 transactions (first to themselves and second to a merchant) the merchant will wait a little bit longer before getting the money if the first transaction is confirmed in the first place. This looks like a violation of the rule, but it's completely non-critical.
it's not clear why...
if 2 * 1/10th are deducted then he violated the 1/10th per day rule... so one of the tx should have been ignored
also, if instead of buying one thing, he buys 19 things, and the merchants are not connected between them, 20 * 1/10th would be deducted. Except he only has 10/10ths. That's a double spend.
if 2 * 1/10th are deducted then he violated the 1/10th per day rule... so one of the tx should have been ignored
also, if instead of buying one thing, he buys 19 things, and the merchants are not connected between them, 20 * 1/10th would be deducted. Except he only has 10/10ths. That's a double spend.
Nothing bad will happen if someone spends more than 1/10th of the balance. The rule is set to avoid risk of spending more than 100% of coins.
Merchants don't need to be connected each other. They need to be connected to the network.
it's not clear why...
if 2 * 1/10th are deducted then he violated the 1/10th per day rule... so one of the tx should have been ignored
also, if instead of buying one thing, he buys 19 things, and the merchants are not connected between them, 20 * 1/10th would be deducted. Except he only has 10/10ths. That's a double spend.
if 2 * 1/10th are deducted then he violated the 1/10th per day rule... so one of the tx should have been ignored
also, if instead of buying one thing, he buys 19 things, and the merchants are not connected between them, 20 * 1/10th would be deducted. Except he only has 10/10ths. That's a double spend.
Nothing bad will happen if someone spends more than 1/10th of the balance. The rule is set to avoid risk of spending more than 100% of coins.
Merchants don't need to be connected each other. They need to be connected to the network.
Jump to: