NXT :: descendant of Bitcoin - Updated Information

[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!

[pandaisftw]

I don't know if this has been answered or not, but have multi-transactions been implemented yet? For example, I can send to 50 different addresses in one transaction.

Otherwise, wouldn't distributing dividends to asset holders be extremely expensive for the dividend dispenser (assuming they have a large number of stakeholders)?

[bitcoinpaul]

I don't know if this has been answered or not, but have multi-transactions been implemented yet? For example, I can send to 50 different addresses in one transaction.

Otherwise, wouldn't distributing dividends to asset holders be extremely expensive for the dividend dispenser (assuming they have a large number of stakeholders)?

Fee will be lowered.

[Come-from-Beyond]

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.

Let's decide what a criterion to use for choosing a duplicate. We remove:

1. A transaction with lower fee
2. A transaction with earlier timestamp
3. A transaction that is received later

[swartzfeger]

I'm thinking out loud here -- the last dozen pages or so have infected my brain.

Basket currencies.

You're the leader of a newly formed country and -- voila! -- oil is discovered beneath the presidential palace. Exxon, Halliburton, Dick Cheney and Paul Wolfowitz come in and drill oil rigs across your land (setting up loans you can never hope to repay and forever cursing your countrymen to servitude, but that comes later in the story).

You decide to peg your new currency to a basket of USD, GBP and an X portion of bbl of oil/USD (currently $100/bbl). Cheney tells you oil's going to the moon, so this should help boost your currency.

how is your basket currency (a Nxt asset?) derived from multiple issuers?

Someone holding BTC wants to buy this new currency (10 min confirmation) from someone selling in NXT (instant). How can this not be gamed with three fluctuating assets in a basket with a disparity in confirmation times?

Or does party A wise up, ditch his BTC in favor of NXT and do a NXT<-basket->NXT exchange?

What am I missing here?

And is a basket currency -- or an asset pieced together from multiple issuers -- doable? We're not only talking about Alice trading for an asset from Bob, but an asset that's assembled in realtime from three separate issuers. So the buyer/seller need synced, but the issuers do as well.

Am I overcomplicating this?