Topic: NXT :: descendant of Bitcoin - Updated Information - page 680. (Read 2761645 times)

Too tired to debate you tonight, but I think you have shown that penalizing a 90% stakeholder is difficult. I have heard the "impossible" word too many times, when it turned out it actually wasnt impossible. Unless you have a mathematically sound proof, I would avoid impossible. Insanely difficult, OK, impossible I doubt it is impossible.

For example, we can track the path the funds have taken into the smaller accounts and combine them into a single 90% attacker. I guess the attacker would have to use NXTcash to avoid being correlated. Another way to group a cooperating group of minority accounts is to identify characteristics of the attack and penalize any node with similar enough characteristics. Not exactly a kind thing to do, but the assumption is that we are at red alert network being attacked mode, so if there are some false positives who cant forge for a bit, I think that is acceptable.

James

I am right there with you.  That is the bedrock foundation of making NXT a stable financial system.

Dont know about the technical aspect of the core and I accept both what you say and what CIYAM said about the necessity of pooling.

the reward coin on a higher layer can also be a good solution along the same principle:

provide motivation/hope/exceitment to the low balance person to keep forging. who doesnt like the lottery and if you can win X every day, hour, minute that't unrelated to your holding level of Y it will provide the motivation to keep within the network.

this is all until such time that the network is busy, fast and large enough- which is i guess another reason to take it to the higher layer.  

and to Ricky: I dont have a problem with rich getting richer- isee it just like dividends from holding more shares. yet- this is an attempt to solve a real world motivational aspect that will likely be mute when the ecosystem grows

From my perspective the "fairness" or not is not even a consideration.

I am trying to "protect the network" and "the blockchain" only.

So far he has produced no mathematical proof and I've already shown that the very idea of being able to penalise the 90% stake holder (as a whole) is *impossible* (as the stake holder just divides up his stake into multiple accounts so only 1 account would get penalised for each block).

I am not going to propose any changes until I have some "math" to back them up (so I don't want people to "believe in me" any more than BCNext) and it will ultimately be up to the community to decide what path to take.

Never forget that NXT (unlike BTC) is a ZERO SUM system.  There are no new coins every X minutes being created by mining.  This means that if you gimmick the system to put more NXT in one guy's pocket, it means there is less NXT going in somebody else's pocket.  This naturally leads to

BTCNext's First Law:  "For every increased incentive created in one part of the NXT system, there is an equal and opposite disincentive created elsewhere in the NXT system".

If you haven't identified the disincentive created by your ideas to improve somebody's lot, you haven't done your homework.  The current system assures that EVERYBODY GETS THE SAME RETURN ON THEIR INVESTMENT.  For a first cut at distributing forging rewards, this is a pretty good idea.  Every NXT holder has the opportunity, (if EVERYBODY were to forge simultaneously) to get the same ROI, the SAME interest rate on their "savings account".  Saying the "rich will get richer and the small guy will not make enough" is a TRUE STATEMENT, and also a snapshot of the Achilles heel of a Proof of Stake system (and many if not most national fiat currencies).  It is also true to say, "Both the rich guy and the small guy are getting the same savings account interest rate on their stockpiled, saved NXT".  So the current system has an element of equality in it as well as an element of perceived injustice.

NXT is an experimental attempt to create a stable economic system.  This is a completely different proposition than creating a fair social system.  Good luck trying to merge the two.

It seems a bit premature to be putting in so much effort now before we even know what the third part of the plan is. I am assuming TF will be fully revealed at that point. My loyalty to BCNext is that so far, he has done all the things he said he would and he hasn't given me any reason to doubt that he wont continue to do so.

BCNext says the final TF will be immune to 90% attacks.

Until it comes out in April, that's good enough for me. Once it comes out, then we can start to analyze it to make sure it is 90% attack proof. All of the "its not fair" stuff is a bit tiring. ANY type of reward system can be built on top of NXT to achieve whatever feedback to the overall network that we want. It wont be super precise, but if we want more nodes, we can incentivize more nodes. If we want more accounts, we can incentivize more accounts. There is no need to do this by changing the NXT core, certainly not before we get fractions, escrow and other core features.

James

There r indeed 12 trades. Check ur response parser for getTrades.

It's a bug related to unconfirmed balance.

Is it? Just because it hasn't been attacked yet doesn't mean it "won't" or "can't".

We have had no mathematical analysis (which we are hopefully soon going to have).

I suggest the decisions are made upon "math" rather than "gut feelings" or "loyalty" to BCNext (he did say "not to trust him").

These are all very creative ideas, but there is no reason to change the NXT core for this. We can just create a rewards coin on top of NXT. Then whatever type of reward, lottery, etc. can be encapsulated in that coin. Messing with forging is VERY dangerous. Can anybody really guarantee than any change of the magnitude being discussed will actually be a stable network? It is working now, why fix it?
Add stuff on top, dont mess with fundamental forging process. I believe BCNext is the MOST capable person for making changes to forging algo. Until someone can convince me that they understand the ramifications of any changes to forging, I will not support changing forging. Especially just to make it more "fair", whatever that means.

Imagine a guy who is juggling while on ice skates, during an earthquake. Do you really want to mess with his balance to make him change his hat?

James

http://www.nxtcrypto.org/nxt-podcast/nxt-crypto-minute-6

4 plans? Damn, I always thought, there are 3.

No - the pool controls x amount of accounts so has greater forging power (otherwise no point in being a "pool" - I don't think we should actually try and stop "pooling").

Also pools are necessary if we want to be able to create "interest bearing accounts" (which I think will be quite popular) and ramping up to 1000+ TPS will require some decent servers (which aren't free).

We are basically trying to work out if the "penalty" should even exist (IMO it should not) and try to make sure that small forgers still have a "reason" to forge (even if the rewards are not much).

If you leave your client on for 24 hours (1440 minutes) then you are forging.  Your client is broadcasting its availability to forge the next block, and there is a lottery system going on once a minute behind the scenes that your 11.5K NXT is participating in to win you the right to forge the next block.  Wait long enough, you will win that lottery at some particular minute, and you will forge a block.  As for monitoring your "progress" - I am not sure if you can really do that.

The two arrows represents "transactions in and out of your account".  The globe / peers is just an item of general interest - your client is not communicating with all the computers on the NXT network, only this subset.  The puzzle piece is data about the most recently forged blocks. 

actually if it is completely random it shouldnt matter if its a pool or a high balance person since the system will be blind to this. it will only relate to 1NXT at a time- so pulling or dividing an account will not give an advantage.

@AE devs: I seem to be having issues with the AE: When I call 'getAssets', I get these 6 assets, created today after CfB restarted the testnet:


getAssetIds

assetIds - ['

9076231045093640293', '
2952478044871531870', '
6525075746265167591', '
16739598998421896224', '
5788088280578443047', '
7761388364129412234', '
12806307819013617780']

I know thst these were created after testnet restart today, because earlier today there were zero assets, and I issued the first one.

Now I look at 'getTrades' for each of these assets, and I get  a total of three trades:

9076231045093640293
trades - []


2952478044871531870
trades - [{'timestamp': 8034990, 'askOrderId': '2306609193939033899', 'price': 46000, 'bidOrderId': '13607793337915669303', 'quantity': 1}]


6525075746265167591
trades - [{'timestamp': 8027556, 'askOrderId': '12546374603755785265', 'price': 5, 'bidOrderId': '234179978827995502', 'quantity': 33}]


16739598998421896224
trades - [{'timestamp': 8021490, 'askOrderId': '16804729641686889636', 'price': 13500, 'bidOrderId': '16894845653194739948', 'quantity': 5}]


5788088280578443047
trades - []


7761388364129412234
trades - []

12806307819013617780
trades - []



However, looking at 'getState', I see 12 trades.




getState

totalMemory - 259522560
time - 8045612
numberOfTrades - 12 <---------------------  



What is wrong there?
Also, there is the persistent issue with the Orders not appearing any longer, or 'not enough funds'

Can anyone of you confirm this, or is it my client messing up?


     



cumulativeDifficulty - 2309274722555977
numberOfPeers - 4
availableProcessors - 2
version - [email protected]
numberOfUnlockedAccounts - 25
maxMemory - 259522560
freeMemory - 100166296
numberOfTransactions - 132339
numberOfVotes - 0
numberOfAccounts - 25102
lastBlockchainFeeder - holms.cloudapp.net
numberOfAssets - 7
numberOfOrders - 16
numberOfAliases - 61320
numberOfUsers - 32
numberOfPolls - 1
lastBlock - 3490252272406714692
numberOfBlocks - 74985
totalEffectiveBalance - 99823172900

automated multisig gateway status.

Deposits seem to be working pretty good, even multiple deposits at the same time to different addresses.

I have constructed multisig rawtransactions that have worked, except for the fact I can only get it to work on one server so far. probably due to system clock differences. The big problem now is that if I need to use more than one vout for a withdrawal, it doesnt fit into a tiny little AM. I either have to massively compress it or setup a point to point network for the signing of multisig. There could easily be half a dozen inputs required for a transaction and no amount of compression will make that fit into 1K. I could have each server calculate the rawtransaction independently and theoretically they should be identical. This might actually be a good way to build in peer verification. However, in case there is the smallest difference, it will probably not verify and tracking down reasons for small variations in a rawtransaction, well, not happy land.

Gotta rest for a bit before tackling this problem.

Oh, I also figured out a much easier way for people to be able to test this. When it is ready for testing, just post your DOGE address and I will send you some DOGE for testing along with a deposit address. I will set the withdrawal address to your DOGE address. I believe there is even an online DOGE wallet, so no need to install DOGE-qt. No need to compile any source code. Since the gateway uses the "sender" field in the AM to verify you are the owner of the NXT acct, I dont think it is so easy to spoof gateway_AM packets. Havent really bullet proofed that yet as we need to have basic functionality first.

Once the gateway has your deposit and withdrawal address, the DOGE wallet essentially becomes and extension of NXT AE. Send DOGE to deposit address and it appears in "My Assets". Transfer the DOGE asset back to the issuer and it appears in your DOGE wallet. Substitute any bitcoind fork for DOGE. Imagine them all at the same time!

I will be offline on Wed, not sure if I will have a stable release before then. The only thing I think I am relying on from the AM is the withdrawal address. If the security of this becomes an issue, we can always make it a manual process to update. I havent code reviewed for this yet, but I believe that I am basing all money transfer decisions based on fully confirmed bitcoind or NXT blockchain events. I am also drilling down to individual vouts to avoid any transaction malleability issues. At least I think I do. Most of the gateway_AM's are basically receipts of what has happened to create a distributed database of gateway transactions. I know I am not supposed to be able to make this automated cross chain stuff work, but I am not sure why I am not supposed to be able to, so I keep working toward what I believe is a cool solution.

James

Similar to what I had suggested earlier - effectively we change the "stake" to the number of >x balance accounts that you have (where we would set x at some low value like 1 NXT).

So a large stake holder will have to divide up their holding into many (millions?) of accounts to achieve the same "power" they currently have.

This works best with pooling of course (rather inconvenient otherwise) but without penalty still gives small forgers "a reason to forge".

Also note that I am wanting to work with the math guy on determining the best solution before I propose any *actual change* from BCNext's plan (I am not convinced about the 90% thing anyway and would like to see some "hard evidence").