NXT :: descendant of Bitcoin - Updated Information

[Eadeqa]

I suspect some nodes could just collect transaction fees without forwarding the request to the "hub". Even worse, the node could send a fake transaction to the "hub". It takes bitcoin miners 10 minutes to confirm a transactions, so the Nxt network would not  know the node sent a fake transaction for at least 10 minutes -- at least after one confirmation on bitcoin's blockchain.  

I;m sorry but the above is incorrect.....Nxt block will  be every 60,000ms == 1 minutes....we can even reduce it to 10 seconds.

The topic was bitcoin transactions that take 10 minutes on average for one confirmation.  There is no reason to believe we can trust anonymous Nxt nodes to perform bitcoin transactions by forwarding them to some "hubs" without serious security and technical implications

[1715002486]

1715002486

[pinarello]

Might I suggest that you do not hold your breath as you wait for the apology?

I obviously can’t stay in a community where four words and a stupid smiley makes somebody wish you death and don’t even think about apologizing (don’t bother doing it now in case your consciousness suddenly wakes up, it’s too late).

And I am tired of being one guy on the other side of everybody else. A cohesive community is much more important than stupid arguments.

So that’s the end for me.

Please withdraw all your money from the exchange, it will be closed in a few days.

Thank you to those people who said kind words.

And thank you to the people who were always nice to me, you know who you are, I am going to miss you.

Sad, I will miss your point of view on surten subjects.
This is a blame on the community in general that "they" succeeded to make you leave.

wish you all the best
Pin

edit: thank you for setting up that exchange in time it was needed, and most of all you didnt get a dime for it!

[landomata]

I suspect some nodes could just collect transaction fees without forwarding the request to the "hub". Even worse, the node could send a fake transaction to the "hub". It takes bitcoin miners 10 minutes to confirm a transactions, so the Nxt network would not  know the node sent a fake transaction for at least 10 minutes -- at least after one confirmation on bitcoin's blockchain.  

I;m sorry but the above is incorrect.....Nxt block will  be every 60,000ms == 1 minutes....we can even reduce it to 10 seconds.

The topic was bitcoin transactions that take 10 minutes on average for one confirmation.  There is no reason to believe we can trust anonymous Nxt nodes to perform bitcoin transactions by forwarding them to some "hubs" without serious security and technical implications

Yes you are correct....I have removed by post.

[Jean-Luc]

Btw, what do u think of the approach when dumb actions, like an attempt to cancel a non-existent bid order, r processed without sanity checks? The fee is paid, transaction is added to the block but the state is not changed.

I don't like the idea, at least in this case it is very simple to enforce such a check, in Transaction.Type.ColoredCoins.ASK_ORDER_CANCELLATION just add:

boolean validateAttachment(Transaction transaction) {
                    Attachment.ColoredCoinsAskOrderCancellation attachment = (Attachment.ColoredCoinsAskOrderCancellation)transaction.attachment;
                    if (Order.Ask.getAskOrder(attachment.getOrderId()) == null) {
                        return false;
                    }
                    return Genesis.CREATOR_ID.equals(transaction.recipientId) && transaction.amount == 0;
}

[jl777]

I suspect some nodes could just collect transaction fees without forwarding the request to the "hub". Even worse, the node could send a fake transaction to the "hub". It takes bitcoin miners 10 minutes to confirm a transactions, so the Nxt network would not  know the node sent a fake transaction for at least 10 minutes -- at least after one confirmation on bitcoin's blockchain.  

I;m sorry but the above is incorrect.....Nxt block will  be every 60,000ms == 1 minutes....we can even reduce it to 10 seconds.

The topic was bitcoin transactions that take 10 minutes on average for one confirmation.  There is no reason to believe we can trust anonymous Nxt nodes to perform bitcoin transactions by forwarding them to some "hubs" without serious security and technical implications

What if something like:
https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment#Zero_knowledge_proof_to_binding

or https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

was implemented in the NXT core? Granted I dont understand how we can effectively escrow other crypto balance, but I am hopeful that there is some multisig or zeroknowledge method that achieves this effect.

I guess we can always have Evil Bob modifying the NXT core, so really the key is to have a cryptographically secure way to achieve the cross chain trading.

I dont claim to understand either of the above docs, but I think it might be possible for a trustless solution that can be trusted. Hey, I never said it would be easy.

James

Edit: what the CIYAM says below

[CIYAM]

@CfB - the "secret" doesn't unlock the bitcoins "on its own" but instead needs to be accompanied by a <sig> check (so no arbitrary 3rd party could come along and "steal" the bitcoin).

Basically person B has to provide a signed (but incomplete) tx to person A in order for A to be able to get the coin from B. Understand B won't do that until A has also provided him with the same (for the other chain) incomplete (but signed) tx (with the *same* SHA256 value being the "key point").

In order for A to get B's coin A will *have* to "publish" the "secret" (unless A also has B's private key) which then allows B to get the coin from A (due to the same secret being used for both scripts).

Understand that A cannot get *back* the coin (other than via the signed "nLockTime" refund) nor can anyone other than B *get* the coin as the coin is locked to a multisig address (with a clever script).

BTW - provided that A's refund timeout is a lot greater than B's there should be no "race condition" issue either.

[Come-from-Beyond]

Btw, what do u think of the approach when dumb actions, like an attempt to cancel a non-existent bid order, r processed without sanity checks? The fee is paid, transaction is added to the block but the state is not changed.

I don't like the idea, at least in this case it is very simple to enforce such a check, in Transaction.Type.ColoredCoins.ASK_ORDER_CANCELLATION just add:

boolean validateAttachment(Transaction transaction) {
                    Attachment.ColoredCoinsAskOrderCancellation attachment = (Attachment.ColoredCoinsAskOrderCancellation)transaction.attachment;
                    if (Order.Ask.getAskOrder(attachment.getOrderId()) == null) {
                        return false;
                    }
                    return Genesis.CREATOR_ID.equals(transaction.recipientId) && transaction.amount == 0;
}

It's not that simple, coz validateAttachment() will return true for 2 different unconfirmed transactions that cancel the same order. After one of them is confirmed another transaction will never be confirmed. This makes it very cheap to DoS nodes - just send 1000000 transactions that cancel the same order. If we included all such transactions into blocks then DoSing would be very expensive.

Is there another way to counteract the DoS attack?

[jl777]

Btw, what do u think of the approach when dumb actions, like an attempt to cancel a non-existent bid order, r processed without sanity checks? The fee is paid, transaction is added to the block but the state is not changed.

I don't like the idea, at least in this case it is very simple to enforce such a check, in Transaction.Type.ColoredCoins.ASK_ORDER_CANCELLATION just add:

boolean validateAttachment(Transaction transaction) {
                    Attachment.ColoredCoinsAskOrderCancellation attachment = (Attachment.ColoredCoinsAskOrderCancellation)transaction.attachment;
                    if (Order.Ask.getAskOrder(attachment.getOrderId()) == null) {
                        return false;
                    }
                    return Genesis.CREATOR_ID.equals(transaction.recipientId) && transaction.amount == 0;
}

It's not that simple, coz validateAttachment() will return true for 2 different unconfirmed transactions that cancel the same order. After one of them is confirmed another transaction will be removed from unconfirmed transactions list. This makes it very cheap to DoS nodes - just send 1000000 transactions that cancel the same order. If we included all such transactions into blocks then DoSing would be very expensive.

Is there another way to counteract the DoS attack?

If it prevents Dos attack then I think that is ok to be mean about charging for silly transactions. Will the caller get error code?

[Come-from-Beyond]

@CfB - the "secret" doesn't unlock the bitcoins "on its own" but instead needs to be accompanied by a <sig> check (so no arbitrary 3rd party could come along and "steal" the bitcoin).

Basically person B has to provide a signed (but incomplete) tx to person A in order for A to be able to get the coin from B. Understand B won't do that until A has also provided him with the same (for the other chain) incomplete (but signed) tx (with the *same* SHA256 value being the "key point").

In order for A to get B's coin A will *have* to "publish" the "secret" (unless A also has B's private key) which then allows B to get the coin from A (due to the same secret being used for both scripts).

Understand that A cannot get *back* the coin (other than via the signed "nLockTime" refund) nor can anyone other than B *get* the coin as the coin is locked to a multisig address (with a clever script).

BTW - provided that A's refund timeout is a lot greater than B's there should be no "race condition" issue either.

Hm, I got only 10% of what u said. And I bet I got it wrong.

Well, look at it closer when will be implementing this in practice.

[Come-from-Beyond]

Will the caller get error code?

Depends on client software.

[CIYAM]

Hm, I got only 10% of what u said. And I bet I got it wrong.

It actually is rather tricky to explain (so my fault at not explaining clearly enough) - but it is actually a very elegant solution to a very tricky problem and in order to do NXTCash I think we are going to need something very similar to this.

[jl777]

Will the caller get error code?

Depends on client software.

As long as it is possible for client to get error message, then I say prevent Dos attack is much more important than not charging fee from silly call. It seems the person was expecting to pay a fee anyway.

[Emule]

Might I suggest that you do not hold your breath as you wait for the apology?

I obviously can’t stay in a community where four words and a stupid smiley makes somebody wish you death and don’t even think about apologizing (don’t bother doing it now in case your consciousness suddenly wakes up, it’s too late).

And I am tired of being one guy on the other side of everybody else. A cohesive community is much more important than stupid arguments.

So that’s the end for me.

Please withdraw all your money from the exchange, it will be closed in a few days.

Thank you to those people who said kind words.

And thank you to the people who were always nice to me, you know who you are, I am going to miss you.

seems like the filth′i·ness of "bo bird", "opticalcarrier", did it again, 4 person i see leaving cos of his filthy mouthing and treathening he is a real asset to your community

[mikesbmw]

Guys:
Been waiting for a good bumper sticker design, got bored and did one myself:

279mm x 76mm, when printed.
Would like feedback on it, might be good to have it in the hands of the guys at Berlin conference if it gets the green light

Leave your feedback on the marketing thread here on BTT:
https://bitcointalk.org/index.php?topic=412243.530
or on Nextcoin.org:
https://nextcoin.org/index.php/topic,3540.15.html

Going to bed now, really.

I don't get all the dark themes.
It makes it look, well, dark/evil/bad/star wars

Personally I would make the theme MUCH brighter. Give it a light airy look.
One of the USP's IS green / lightweight after all.

[Jean-Luc]

It's not that simple, coz validateAttachment() will return true for 2 different unconfirmed transactions that cancel the same order. After one of them is confirmed another transaction will never be confirmed. This makes it very cheap to DoS nodes - just send 1000000 transactions that cancel the same order. If we included all such transactions into blocks then DoSing would be very expensive.

Is there another way to counteract the DoS attack?

The second invalid transaction will be removed when its deadline expires. I don't like including invalid transactions in the blockchain just for the purpose of preventing a theoretical attack. By that logic we shouldn't bother validating transactions at all. And once we allow invalid transactions in the blockchain, we can't change our mind in the future easily. And a DoS attack can be conducted just by making a sufficiently large number of http requests of the types that are expensive to process anyway, whether they create transactions or not, so we need a better way of dealing with those.

[jl777]

Might I suggest that you do not hold your breath as you wait for the apology?

I obviously can’t stay in a community where four words and a stupid smiley makes somebody wish you death and don’t even think about apologizing (don’t bother doing it now in case your consciousness suddenly wakes up, it’s too late).

And I am tired of being one guy on the other side of everybody else. A cohesive community is much more important than stupid arguments.

So that’s the end for me.

Please withdraw all your money from the exchange, it will be closed in a few days.

Thank you to those people who said kind words.

And thank you to the people who were always nice to me, you know who you are, I am going to miss you.

seems like the filth′i·ness of "bo bird", "opticalcarrier", did it again, 4 person i see leaving cos of his filthy mouthing and treathening he is a real asset to your community

So after all the tech discussion, this is the thing you decide to post on?

I dont understand you, I read your posts over in emunie-land and you made a lot of good points. I dont think you are like the clock that is right twice a day.

If you really have any amount of NXT, then you should want the value to go up. Why not help in whatever way you can? Hey, donate 1% to NXTcommunityfund! That will show everyone that you really are big blue whale

James

[Come-from-Beyond]

It's not that simple, coz validateAttachment() will return true for 2 different unconfirmed transactions that cancel the same order. After one of them is confirmed another transaction will never be confirmed. This makes it very cheap to DoS nodes - just send 1000000 transactions that cancel the same order. If we included all such transactions into blocks then DoSing would be very expensive.

Is there another way to counteract the DoS attack?

The second invalid transaction will be removed when its deadline expires. I don't like including invalid transactions in the blockchain just for the purpose of preventing a theoretical attack. By that logic we shouldn't bother validating transactions at all. And once we allow invalid transactions in the blockchain, we can't change our mind in the future easily. And a DoS attack can be conducted just by making a sufficiently large number of http requests of the types that are expensive to process anyway, whether they create transactions or not, so we need a better way of dealing with those.

Ok. Then I need 1-2 days to add validations.

[Come-from-Beyond]

If you really have any amount of NXT, then you should want the value to go up. Why not help in whatever way you can? Hey, donate 1% to NXTcommunityfund! That will show everyone that you really are big blue whale

He is a big blue whale. But he sits with bitcoins, not nxts.

[Jean-Luc]

It's not that simple, coz validateAttachment() will return true for 2 different unconfirmed transactions that cancel the same order. After one of them is confirmed another transaction will never be confirmed. This makes it very cheap to DoS nodes - just send 1000000 transactions that cancel the same order. If we included all such transactions into blocks then DoSing would be very expensive.

Is there another way to counteract the DoS attack?

Yes, override Transaction.Type.isDuplicate() to check for such duplicate transactions, trying to cancel the same order, similar to the way it is already done for alias assignment transactions.

[Damelon]

Might I suggest that you do not hold your breath as you wait for the apology?

I obviously can’t stay in a community where four words and a stupid smiley makes somebody wish you death and don’t even think about apologizing (don’t bother doing it now in case your consciousness suddenly wakes up, it’s too late).

And I am tired of being one guy on the other side of everybody else. A cohesive community is much more important than stupid arguments.

So that’s the end for me.

Please withdraw all your money from the exchange, it will be closed in a few days.

Thank you to those people who said kind words.

And thank you to the people who were always nice to me, you know who you are, I am going to miss you.

seems like the filth′i·ness of "bo bird", "opticalcarrier", did it again, 4 person i see leaving cos of his filthy mouthing and treathening he is a real asset to your community

Could you quit using other peoples problems to create the impression they are connected to you?

It's a despicable tactic.

Fight your own fights.

Also: nxtchg: i will genuinely be sad to see you go. It's a bad thing to receive a death threat and never warranted. Hoping you will reconsider but understand your reasoning. All the best, whatever you decide!