elective-stereophonic
elective-stereophonic
Show Posts - stdset  
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.2

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - stdset

Pages: [1] 2 3 ... 5
1
Transparent Forging / Re: Transparent Forging - the latest info
« on: December 15, 2016, 03:03:31 pm »
I was skeptical, although silent about feasibility of transparent forging from the very beginning.
It's now about a year or more, since they say that TF needs Economic Clustering. Now my questions are:

1) How different is Economic Clustering from Ripple consensus system (at least as it was devised in 2011)

Quote from: jed link=https://bitcointalk.org/index.php?topic=10193.0
Let’s say a node has a public key that the client generates for them. There is no connection between this key and a wallet key. It just allows you to be sure you are talking to the node you think you are.

So when you run a node you choose which other nodes you trust. So you could say “I trust my 3 friends’ nodes, Gavin’s node, and these 5 businesses’ nodes.” This trust just means that you believe these people will never participate in a double spend attack or otherwise manipulate the ledger.
The ledger would basically be like the current bitcoin block chain but it would also have a list of what nodes believe the current ledger to be valid. <hash of current ledger signed by node’s public key> (This list doesn’t have to be complete. Nodes can just collect this list as needed. They could even just ask the nodes they trust if they think the current ledger is valid since those are the only ones they care about)

Transactions are still sent to all nodes connected to the network. There would be a network wide timestamp. Transactions would only be accepted if they were within a certain time period of the network timestamp. So you would need to wait maybe 10min before you could fully trust a given transaction. After this waiting period you could be sure those coins weren’t double spent.

If a node ever encounters two conflicting ledgers it would just go with the one that was validated by more nodes that it trusts.

So there should always be a consensus among the trusted members of the network.

There would be a way to look up particular nodes in the network and ask them questions. (I’m imagining this whole thing running on Kademlia, a DHT)

2) Since they are probably quite different, after all Ripple wasn't a PoS crypto, aren't those differences unnecessary superstructures complicating things over Economic Clustering trust layer?

3) Is TF still in plans for Ardor/Ignis?

2
Core Development Announcements / Re: Announcing Nxt 2.0 Roadmap
« on: October 31, 2016, 04:53:58 am »
Thanks

3
Core Development Announcements / Re: Announcing Nxt 2.0 Roadmap
« on: October 30, 2016, 11:27:12 pm »
And NXT won't become an Ardor childchain? NXT remains intact, Ardor/Ignis is just a spin-off coin?
Nxt remains intact, yes.
Ardor is..... a spin-off coin? I wouldn't call it that.
Ignis is the first child chain on Ardor (with Nxt's current features + more).

I really think you should re-read the OP and
https://nxtforum.org/core-development-announcements/nxt-2-0-overview/   :)
I read it several months ago. And I remember I had an impression that NXT will become Ardor's childchain. But later posts left impression that NXT will stay independent as it is now. It's an important and simple question. I used the word "intact", but unfortunately it doesn't describe the situation clear enough. It's possible to make NXT a childchain and still consider and call it 'intact'. So please give a short and clear answer: will NXT become a childchain or will it remain independent?

4
Core Development Announcements / Re: Announcing Nxt 2.0 Roadmap
« on: October 29, 2016, 07:37:04 am »
And NXT won't become an Ardor childchain? NXT remains intact, Ardor/Ignis is just a spin-off coin?

5
Core Development Announcements / Re: Announcing Nxt 2.0 Roadmap
« on: October 27, 2016, 06:43:02 pm »
Do I understand it right (it's important), that Ignis will be distributed according to NXT 1.0 distribution (not Ardor distribution) at the time of Ardor/Ignis launch (Q3 2017), the snapshot will be instant, not long-lasting like in the case of Ardor?

6
Old Nxt Promotion Topics / Re: The DAO hack is a great opportunity!
« on: July 20, 2016, 04:11:02 am »
It's not us, it's them who make it dirty. Employing censorship and calling their coin a "cryptocurrency" is dirty.
Also, imagine for a while they succeeded with their hard fork. I.e. significant time passed after the fork and Ethereum is still alive and gaining more marketcap. How this precedent could affect other cryptos?
And here are some of their pics:




7
Old Nxt Promotion Topics / Re: The DAO hack is a great opportunity!
« on: July 19, 2016, 01:54:54 pm »
Not sure how Ethereum's struggles has to be beneficial to NXT.
Ethereum is currently the #2 crypto with market cap of almost 1B USD. Guess what could happen to NXT if even just 5% of that marketcap moves into NXT, that already happened btw to some extent. NXT exchange rate started to climb on June 19'th, The DAO hack happened on June 17'th.

NXT already proved that it's strong enough, that's my point. It doesn't matter how many fancy features your favourite crypto has. If it commits acts of censorship, it isn't a crypto at all. You should compare your centralised crypto not to other cryptos but to centralised services. And it comes out that all your fancy features are alredy implemented by banks, centralised exchanges and so on in a more efficient way.

8
Core Development Announcements / Re: Nxt 2.0 Overview
« on: July 01, 2016, 07:34:29 pm »
It was discussed way too much here: https://nxtforum.org/core-development-discussion/nxt-2-0-design/
Your concerns were expressed as well.
I see that you had exactly the same concerns as me. It would be much appreciated if you save me (and probably some other people) time reading all 51 pages (I've already read 5) and provide an answer here.
Answer is: it may or may not happen - noone knows. Core devs just want to dive in and see what happens. We will have some time to trade Ardor as asset back and forth. So we will see if our prediction is a real issue or not before the actual network starts working.
Thanks.

9
Core Development Announcements / Re: Nxt 2.0 Overview
« on: July 01, 2016, 03:28:41 pm »
It was discussed way too much here: https://nxtforum.org/core-development-discussion/nxt-2-0-design/
Your concerns were expressed as well.
I see that you had exactly the same concerns as me. It would be much appreciated if you save me (and probably some other people) time reading all 51 pages (I've already read 5) and provide an answer here.

10
Core Development Announcements / Re: Nxt 2.0 Overview
« on: July 01, 2016, 08:27:57 am »
Since nobody addressed concerns that I expressed in the previous post, let me make a suggestion.
Sidechains/childchains is an interesting concept. I don't know if there are any cryptos that implemented it already, even if there are some, they aren't many. It would be great to implement them in NXT. But since we are a PoS crypto, we must try to concentrate as much value in forging token as possible. There is a mechanism that allows to have sidechains and put most of value into the central token, it is two way peg. That's what Rootstock team currently develops http://www.rootstock.io/blog/sidechains-drivechains-and-rsk-2-way-peg-design
Bitcoin guys are very very smart, but they are also very slow. If NXT implements it before them that would aslo create a lot of positive publicity.

11
Core Development Announcements / Re: Nxt 2.0 Overview
« on: June 30, 2016, 06:47:44 pm »
forging and securing other child chains.
If it's uses will be so limited, the market will probably value it very low. But security of a PoS cryptocurrency is cost of buying enough stake to outstake the honest network. I.e. cheap central token means low security.

12
Core Development Announcements / Re: Nxt 2.0 Overview
« on: June 30, 2016, 02:30:46 pm »
A question:
what uses, except paying fees will the central token have?

13
I like the name, sounds like a hybrid of Arnor and Mordor.

14
Old Nxt Promotion Topics / The DAO hack is a great opportunity!
« on: June 30, 2016, 11:56:40 am »
Ethereum community now straggles among different fork propolsals. And it looks like they (at least their leaders) incline to do one fork or another. Not only it will kill Ethereum, but it will also undermine credibility of all public blockchains.
In such situation it's very beneficial for NXT and for the cryptocurrency movement as a whole, to remind people, that in similar situation, after the first Bter hack, NXT didn't fork. The community was strongly against forking, and it didn't happen.

15
When nodes download the blockchain they greedily process all chains they see. If there is a fork at height N, they choose the chain that has better difficulty at height N+720, and abandon the other chain. They don't care about the final difficulty of each chain, they only care about the difficulty 720 blocks after the fork.
Thanks for this clarification, it changes everything. Now it seems to me NXT is well protected against this kind of attack.

16
I do not understand how A can fake the 2N transactions needed to justify the increase in the account. In this attack, A changes the block chain starting from a specific point after Block 2N and this introduces a discontinuity that can be detected easily.
Maybe I am missing your point.......
I'm not sure why you are talking about 2N transactions. A doesn't fake anything. He performs consecutive withdrawals and deposits from/to the exchange, keeps all withdrawals and omits all deposits on his secret fork. On his fork it looks like a long series of withdrawals from the xchange to his account(s).

P.S. This attack is dangerous because it doesn't require a lot of resources to implement, in other words it is very cheap. But it won't work well on Bitcoin/Peercoin forks, because the two forks will soon become largely incompatible, in the sense that a valid transaction from one fork will likely be invalid on the other.

17
I consider four actors in this scenario. A is the attacker, E is the exchange, O is an account online during the attack, F is an account offline during the attack.
Assume that when the attack starts the account balance of A is 0 while the balance of E is 100. Neglect for simplicity transaction fees.
When A starts to attack the blockchain, it creates this sequence of transactions:

TX1  A <- E  True Bal. A=10 stored in Block N
TX2  A <- E  True Bal. A= 0  stored in Block N+1  and so on

In this simple model, after 20 transactions balances have not changed, while in the same account in the secret fork the value is 100. At that point, assume that the stake stolen by A is large enough to create a fork that can disrupt the overall system.
According to the new forked chain, E is the loser, A the winner, while O and F have to decide which chain to join. If this is the model, then A can perform an attack only after block N+20.
If this is the case, then I assume that up until Block n+20 O remains with the honest block chain since A can not rewrite the history of the chain before having stolen the funds. When A presents the new chain, O can safely decide to support the honest block chain since the blocks that justify the stake of A are not consistent with the known evolution of the chain. If O decides to remain with the honest chain, then its transactions can convey this choice by a hash that shows the chain O is in.

The real problem is F. When F goes online after the attack is complete, it finds two forks, the one presented by A "stronger".

However, another source of information available to F is provided by other nodes that have remained online and keep producing transactions linked by a hash to the honest and apparently "weaker" chain.
Is this scenario a correct description of the attack vector you are proposing?
In this case, there could be some information that can be extracted a pattern analysis of the block chain and from the (full) nodes that have remained online during the attack providing continuity to the environment.
Yes, this description seems to be correct.
I however prefer to use different wordings for some parts of this description. For example:
O can safely decide to support the honest block chain since the blocks that justify the stake of A are not consistent with the known evolution of the chain.
I'd say simpler: only the limit on the reorg depth prevents O from switching to the attacker's fork. We have some set of formal rules for conflicts resolution and this is the only rule that holds the attack back in this case.
However, another source of information available to F is provided by other nodes that have remained online and keep producing transactions linked by a hash to the honest and apparently "weaker" chain.
F doesn't know which nodes were online and which were offline during the attack, the attacker can run multiple nodes, the fork presented by A looks as legit as the true legit fork. We can hope that the user running F will be aware of the attack at the time of launching his node and he will be able to choose the legit fork through reading forum threads, blogposts, etc. The easiest solution for the community in this situation that comes to mind is to spread the legit fork with a torrent published on well known websites, signed by well known people.
But it would be much better to make this scenario impossible to implement in real world (in theory it is still possible to buy priv keys for empty accounts holding 50+% of total coin supply that were all funded at the same time).

18
I beleive it's possible to eliminate this weakness in the following way:
We add a new field to transactions, let's call it AS (stands for Account State), such that anybody can deterministically calculate it for any account for any block height, up to current. For example AS can be a hash of all incoming and outgoing transactions for that account ordered according to some rule. In transactions AS is signed like everything else.

Now let's consider the scenario when an adversary sucks stake from an exchange. He wants it to work the following way:
He buys small amount of NXT on an exchange, withdraws it, thus funding a private key, starts his own secret fork (he can have a small amount of old NXT for that purpose) then deposits that amount back to the exchange but censores this depositing transaction on his fork. Then he makes another withdrawal thus funding another privkey on both forks and deposits NXT back to the exchange, but again excludes this transaction from his fork and so on. He can continue doing that untill the exchange account is empty on his fork (the exchange account isn't empty on the legit fork of course). This way he can steal stake little by little from several exchanges at the same time and achieve his goal of outstaking the entire honest network on his secret fork. Then he waits some time for his fork to become longer than the legit one and publishes it. Now only the limit on the reorg depth prevents the catastrophe. But IMO this limit is a weapon of last resort that it's better not to use.

And with our improved transactions he can't carry this plan out because all witdrawals except the first become invalid on his fork.

19
Core Development Discussion / Re: PoS Algorithm
« on: March 08, 2016, 02:01:21 pm »
The more stake forges the better. If for example 5% of total coinsupply forges, an adversary only needs to gain control on slightly more than 5% of total stake to outstake the honest network. If 90% forges the attacker needs to control at least 90% of the stake on his fork to achieve same results. Now why would most users forge if there's a risk of funds loss? I wouldn't if you ask me. So either I misunderstood their proposal (didn't watch the video, just read the summary) or it's extremely, surprisingly stupid.

20
Historic keys attack is a well known attack against PoS cryptocurrencies...
.. and had been  analised here:

Quote from: kushti link=https://bitcointalk.org/index.php?topic=1382241.msg14062788#msg14062788
That so-called "History attack" is discussed in the "Interactive Proof-of-stake" paper of mine http://arxiv.org/abs/1601.00275
It is discussed there with respect to proposed IPoS, not with respect to classic Peercoin PoS nor with respect to NXT PoS.

Pages: [1] 2 3 ... 5
elective-stereophonic
elective-stereophonic
assembly
assembly