Topic: [ANN] Nxt :: descendant of Bitcoin - page 136. (Read 383813 times)

The raised funds will be spent for further development (for example, now I'm negotiating with guys who are willing to create a product similar to http://bitcoincard.org/).  You will not get the bitcoins back in any case so temptation shouldn't be taken into account.  If you worry that you will not get NXT then go to http://88.198.210.245:7875/ to see it's not a vaporware.

It's a terrible idea to distribute NXT equally to the first 1000 forum members.  There are so many sockpuppets here.

- it is counterproductive for early participants, because their share in Nxt will be significally reduced with new participants coming.

This initial distribution scheme provokes people to send more and more of BTC, until the anonymous author did not resist the temptation and decides to disappear.

If the author does not want to rip people off, he should change the distribution scheme for less provocative. For example, distribute Nxt equally to the first 1000 forum members (with >1 month old account and > 30 posts), which send 0.01BTC via blockchain.info.

Thank you for the advice.

Yes, I was assuming the longest chain always wins and only examining tie breakers. The tie breakers do not need to be enforced as protocol rules.

If you code them as default client behavior, they will likely persistently influence how the network operates.

The first tie breaker in my opinion should be prefential treatment of blocks that have a lower stake adjusted hit. These should be the first blocks seen by the network. However, if a competing miner post dates his timestamp by 15 seconds, he can potentially get in ahead of the true winning block. Replacing blocks that shouldn't have won with blocks that should have won discourages cheating on the timestamp. This is not really necessary, so if you don't like this tiebreaker it just ignore it. Even if every miner post dates timestamps, the system will still work.

The above tie breaker takes care of blocks signed by different keys. The chances of identical stake adjusted hits for these blocks are infintesimal. You still need a tiebreaker for comparing nonidentical blocks signed by the same private key. I guess the miner's goal would just be to cause temporary network forking. Potentially, this can help you double spend if you are targetting someone who accepts txns with just a few confirmations. To help the network prevent a complex fork, it would be good to establish a common criterion for comparing blocks based on the txns they contain. The arbitrary rule you suggested is fine. This tiebreaker is quite important. Even though no harm is done in the long-term, an attacker who feeds parts of the network say 1000 distinct blocks will cause a major service disruption. Forking could continue for a long time since several branches could be extended simultaneously, carrying the forks over into the next block.



Finally about 'the longest chain'. Longest has to mean the chain with the highest summed difficulty not just the most blocks.
Maybe this is obvious, but I just want to make sure you are aware of this.

Any suggestions how to implement colored coins before I start coding?  I am planning to start development next week.

What about the rules:
1]  The longest chain wins.
2]  If two chains are equal then a chain with a greater last block id wins.
?

Id of a block = 8 first bytes of SHA256(BlockHeader) in the little-endian byte order.  Block header contains hash of all transactions.

Would it be helpful here if there was some unambiguous replacement rule?
i.e. Let's say chain A's and B look like

Identical History - Most Recent Block A
Identical History - Most Recent Block B

Say I communicate with a peer. I have "Identical History - Most Recent Block B." He has "Identical History - Most Recent Block A."
 
Can we establish an unambiguous set of rules identifying the chain that the standard client prefers. This doesn't have to be formalized as a chain selection method.
The two chains can be equivalent formally. However, informally it would likely speed convergence if we had a simple comparison rule for chains of equal length.

I'd suggest the following:

1) If hit of Identical History - Most Recent Block A < hit of Identical History - Most Recent Block B, then the peers should replace Identical History - Most Recent Block B with
Identical History - Most Recent Block A.
2) If hit of Identical History - Most Recent Block A = hit of Identical History - Most Recent Block B [this happens if one guy sends out many blocks], then hash the txn data in Block A and hash the txn data in Block B. If hash(txn data in Block A) < hash(txn data in Block B), then the peers should replace Identical History - Most Recent Block B with Identical History - Most Recent Block A.

The idea is to avoid forking by setting some 'customs' for choosing between two similar chains. The 1st custom says we should prefer someone who could have mined a block at an eariler timestamp. The 2nd custom allows us to arbitrarily select one of two similar blocks. Again this doesn't need to be enforced, it would just be an informal client rule.

No you need the full 1440 block maturity period.

To explain further, say we have address A with 1 coin in it at block 1000. This 1 coin never moves.
Suppose that address A receives 4 additional coins in block 3000 and then attempts to mine in block 3300.

There are 3 possible ways of handling this:
1) address A is treated as having 5 coins worth of stake   [this won't work, it opens up an attack vector where coins are moved across established addresses to mine many consecutive blocks. 1 block maturity means that I have to mine 2 blocks on a private chain before I can start full-on cheating. This is a negligible obstacle. As long as I can get 2 legitimate blocks in a private chain before the public chain gets 720 legitimate blocks, then I can attack successfully.]
2) address A is treated as having 0 coins worth of stake [this won't work, it opens up an attack vector where competing miners are shutdown by sending their public keys tiny amounts of coins]
3) address A is treated as having 1 coin worth of stake until block 4440 when it is treated as having 5 coins worth of stake [this is the proper approach. You can see immediately that the type of attack in (2) won't work. The type of attack in (1) won't work either. The attacker would need to mine 1440 blocks without cheating before he could begin exploiting a search over addresses with favorable hits. 1440 blocks is longer than the allowable roll-back period of 720 blocks, so the attack is infeasible.]
 
Just implement (3) and you are all good.

1 block maturity period for established addresses should resolve the issue, right?

You have to impose the maturity period on all addresses that have recently received coins not just novel addresses. Otherwise you can attack by moving coins across a set of established addreses.
You also have to allow established addresses to use mature coins to mine even if they also control some ineligible immature coins.  Otherwise, you can attack by sending other miners coins to temporarily disable them.

If you do both of the above, I think you are safe.

For new people downloading the blockchain, you have to allow them to designate trusted sources manually. Otherwise,  some asshole can send them a long irreversible chain, preventing them from catching up to the rest of the network.

This is not the prettiest solution, but I think it can work.

I will describe my suggested solution later. It's quite different and might be too much of a bitch to implement. It's always good to keep alternatives in mind though, even if they are not immediately useful.

No.



After messaging is added the client will provide all this info.

We need a centre where we can view the all of the investment opportunities that people are setting up using the colored coins.  Somewhere to make it easy for investors to browse the shares available (colored coins, basically being 'shares' in anything), and somewhere for businesses/individuals/artists i.e. colored coin issuers to list their project so that they have a page to promote to make it easier to attract investment.

BIG PROBLEM is the laws about equity crowdfunding.  Colored coins are the most awesome way to do equity crowdfunding imho except that equity crowdfunding is unfortunately still illegal in almost every country to due laws relating to private securities (law lags behind technology).  Indigogo (a crowdfunding site) is waiting for the law to change before implementing equity crowdfunding (where project backers receive a share of the profits).  The law in the US is set to change in 2014, but it has already been delayed from 2013.

The only options I see are:

-  Proceeding anyway.  This would mean any investment in colored coins based shares would be illegal.  A centralized exchange is therefore under very high risk of being shut down.  A de-centralized colored coin exchange may well be able to avoid the arm of the law but would be much less popular I'd imagine due to both the illegitimacy increasing risk, and lack of web-based exchanges making it easy to view + promote colored coin projects.  But I could be wrong, maybe people would still invest?
- Waiting for the law the change before implementing the colored coins feature. 

Due to this problem maybe the other special features should be developed first, then by the time they are complete maybe equity crowdfunding will be legal?

I had a small talk with the guy who is launching the stock exchange for Nxt.  He was curious when the colored coins feature would be ready.  Colored coins remove necessity in a third-party service because securities represented by colored coins can be traded for ordinary NXT in an atomic transaction.  This is a superior feature (no trust to anyone required, no fees charged by third-party services) which could make the stock exchange unpopular.  I expect to have colored coins implemented upon the Nxt launch.  A decentralized stock exchange has a big disadvantage though, all transactions require 1 minute to confirm (in average), no high-frequency trading.  I want you all to answer the question:  Do we need a centralized exchange?

No.  Transactions do not affect the signature.

Someone may attempt an "attack" by sending their generated blocks with different transaction sets to different peers.  This will just increase the rate of orphaned blocks.  A few blocks later the network will decide which branch to follow.

Okay, so the txns included  in  each block do not affect the block's generation signature?

comtents == content?

Nth block generation signature = Ed25519.Sign([N-1]th block generation signature).

Edit:  The generator signs two messages each block, generation signature of the previous block and the header of this block which contains payload hash.

Do the block comtents affect the generation signature parameter (I.e. is it a signed message)?

Or is it just the public key of the generator of the previous block?

Tomorrow I will lock the poll, as I can see the majority chose colored coins.

It's the generation signature of a previous block signed by the generator of a current block.

Good move dude!!