Bitcoin Forum
August 21, 2018, 10:22:37 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 146 »
  Print  
Author Topic: [ANN] Nxt :: descendant of Bitcoin  (Read 364026 times)
cunicula
Hero Member
*****
Offline Offline

Activity: 854
Merit: 1003


Stack-overflow Guru


View Profile
October 19, 2013, 08:12:34 AM
 #161


In PoW currency you can remine a block to build a longer chain.  In Nxt the order of generating accounts is determined, you can't create a long chain that contains blocks generated solely by you.  With 51% of the stake the odds to generate a longer chain with 10 blocks are less than 0.1%.  If someone buys a car with NXT they can wait a little bit longer to counteract even 90% attack.

I like that you plan to make things deterministic. My ideas for pure PoS have also been deterministic.

There is a potential problem here though.

How do you deal with AWOL coin-owners? If I can't make a winning chain with 51%, then can the chain continue at all if 49% of coins are lost?

Looking forward to the details so I can see how you address this and other issues.

It's a good chance to tell the details...

Each block has "generationSignature" parameter.  An active account signs "generationSignature" of the previous block with its private key.  This gives 64 bytes which are hashed with SHA256.  The first 8 bytes of the hash gives a number (I call it a "hit").  The hit is compared to the current "target" (64bit number).  If the hit is lower than the target then next block can be generated.

The target for each account is proportional to the balance.  Someone holding 1000 coins gets a 50 times bigger target than someone with 20 coins. Thus the owner of 1000 coins will generate 50 times more blocks than the owner of 20 coins (in the long run).

The target is not constant, it grows each second passed since the timestamp of the previous block.  If noone generated a block on the first second then the target becomes 2 times bigger and so on.  The base target is the target on the 60 second mark.  If there is only a few active accounts then after a long time someone will generate a block because the target will become very big.  If you open the client and log with any funded account you can see a ticking timer in BLOCKS widget.  It shows when the target will become greater than your hit.

Since the private key is used as a seed here, it seems like you could game this with sufficient computing power.

Suppose you mine a block contains 1 txn that sends 1 coin to a novel public key Y. As a miner, you will be able to calculate the generation signature parameter of this block in advance. You can thus know the future target. Each possible public key Y will be associated with a different hit. You can search over possible Y until you find one that allows you to mine two blocks in a row.

I think it would be better to mark each satoshi with a fixed identifier at genesis. You could use these permanent markers to generate hits for each block height.

I'll stop there for now because I would like to hear your response.

Note: I am cautiously optimistic about this project.

▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
        Quickseller is a scammer and sockpuppet of OGdynasty        [/glow][/size]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1534890157
Hero Member
*
Offline Offline

Posts: 1534890157

View Profile Personal Message (Offline)

Ignore
1534890157
Reply with quote  #2

1534890157
Report to moderator
1534890157
Hero Member
*
Offline Offline

Posts: 1534890157

View Profile Personal Message (Offline)

Ignore
1534890157
Reply with quote  #2

1534890157
Report to moderator
1534890157
Hero Member
*
Offline Offline

Posts: 1534890157

View Profile Personal Message (Offline)

Ignore
1534890157
Reply with quote  #2

1534890157
Report to moderator
BOUNTY PORTALS
BLOG
WHERE BOUNTY MANAGEMENT
MEETS AUTOMATION
SIGNATURE CAMPAIGNS
TWITTER
FACEBOOK
MEDIA CAMPAIGNS
AND MORE!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
BCNext
Jr. Member
*
Offline Offline

Activity: 56
Merit: 3


View Profile
October 19, 2013, 09:29:31 AM
 #162

Valid point.  Will adding a generation delay for novel keys solve this problem?  60 blocks (~1 hour) to wait until someone is able to generate blocks, what do you think?
BCNext
Jr. Member
*
Offline Offline

Activity: 56
Merit: 3


View Profile
October 19, 2013, 12:46:26 PM
 #163

Please, vote on the first advanced feature at https://bitcointalk.org/index.php?topic=314008.0

You should choose between

Messaging
Storing messages in the blockchain.  The amount will be determined by the length of a message, this money will be destroyed increasing value of all other coins.  Such messages can be used as digital contracts because they will be signed with the account key.

Two-phase payment
A payment that must be commited.  This should stimulate sellers not to cheat their customers.  A payment can't be rolled back and the sender can't get the funds back in any case.

Voting system
A tool that lets to vote on anything.  Number of voices is determined by the stake of coins.

Colored coins
A system that tracks ownership of any digital property.  More information at http://bitcoin.stackexchange.com/questions/5695/what-are-colored-coins.
Adamlm
Hero Member
*****
Offline Offline

Activity: 804
Merit: 1000



View Profile WWW
October 19, 2013, 01:48:33 PM
 #164

Why don't you implement two features: messaging and colored coins

Come-from-Beyond
Legendary
*
Online Online

Activity: 2044
Merit: 1007

Newbie


View Profile
October 19, 2013, 02:04:45 PM
 #165

I would vote for colored coins and 2-phase payments. This combo would let to trade smart property for BTC, LTC, etc.
matt608
Legendary
*
Offline Offline

Activity: 952
Merit: 1000


Gambling Investment Fund


View Profile
October 19, 2013, 02:13:25 PM
 #166

This is starting to look really promising, I might invest some more.  You only asked for small amounts, but are slightly larger amounts welcome too such as 1-2BTC?

The main issue I see is distributing the coins to enough people.


GIFcoin




.
Gambling
Investment Fund
  Invest in a working business  .......        ✔︎ 
  80% of the net profits are shared .....      ✔︎ 
  Profit share token     ✔︎ 
Follow us & check out the .      whitepaper     .
.
Website    Announcement    Twitter    Telegram    Facebook
Come-from-Beyond
Legendary
*
Online Online

Activity: 2044
Merit: 1007

Newbie


View Profile
October 19, 2013, 02:23:16 PM
 #167

The main issue I see is distributing the coins to enough people.

Agree. Without at least 100 users on start the whole currency is pointless. I would spend collected bitcoins for advertising instead of development of advanced features.
BCNext
Jr. Member
*
Offline Offline

Activity: 56
Merit: 3


View Profile
October 19, 2013, 02:33:53 PM
 #168

This is starting to look really promising, I might invest some more.  You only asked for small amounts, but are slightly larger amounts welcome too such as 1-2BTC?

Thank you.  But we don't really need a lot of funds right now.  All services were promised to be developed free of charge.  The transfer address is for initial stake distribution, not for investment.

The main issue I see is distributing the coins to enough people.

I hope after I publish a beta-test version of the client we will get more users.
BCNext
Jr. Member
*
Offline Offline

Activity: 56
Merit: 3


View Profile
October 19, 2013, 02:34:46 PM
 #169

Agree. Without at least 100 users on start the whole currency is pointless. I would spend collected bitcoins for advertising instead of development of advanced features.

I may follow your advice.
Adamlm
Hero Member
*****
Offline Offline

Activity: 804
Merit: 1000



View Profile WWW
October 19, 2013, 02:37:11 PM
 #170

The main issue I see is distributing the coins to enough people.

Agree. Without at least 100 users on start the whole currency is pointless. I would spend collected bitcoins for advertising instead of development of advanced features.

Like & share, tell people about Nxt
http://altcoins.com/nxt-descendant-of-bitcoin.html

Racer8
Full Member
***
Offline Offline

Activity: 147
Merit: 100


View Profile
October 19, 2013, 05:37:51 PM
 #171

I'm working on blockchain synchronization and have to decide the maximum number of transactions in a single block.  I think that a small number will lead to fee competition, which is good for miners but bad for users.  Any suggestions?

600 tx in block == 10 tps. Looks good to me.
For testing yes.  If this coin becomes the standard in production will 10 tps cut it?  I think not.
B.T.Coin
Sr. Member
****
Offline Offline

Activity: 332
Merit: 250



View Profile
October 19, 2013, 08:06:13 PM
 #172

A special message must be attached to the transaction.  This should be done via blockchain.info which supports such the feature.

I can't find this feature on blockchain.info
Can anybody point me in the right direction? Thanks.

A fine is a tax you pay for something you did wrong.
A tax is a fine you pay for something you did right.
Come-from-Beyond
Legendary
*
Online Online

Activity: 2044
Merit: 1007

Newbie


View Profile
October 19, 2013, 08:45:26 PM
 #173

I can't find this feature on blockchain.info
Can anybody point me in the right direction? Thanks.

albitos
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
October 20, 2013, 12:50:18 AM
 #174

Hey, I have a server that could help in bootstrapping the network and some coins. Need my help? :>
wezelvis
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
October 20, 2013, 12:54:27 AM
 #175

The main issue I see is distributing the coins to enough people.

Agree. Without at least 100 users on start the whole currency is pointless. I would spend collected bitcoins for advertising instead of development of advanced features.

I agree with this 100%. Once the word gets out you run the risk of a few big players sending you large amounts of btc (100+, or even higher). The bonus idea is a good one. With MasterCoin, right at the end in the last few days some big amounts were sent in - 400 btc etc. That could potentially kill this coin.

Maybe you could add a maximum amount people can send you too. Just an idea, to help spread the NXT around more evenly.

I'd say a 100 users is the bare minimum to start. 250 users each having btc amounts under 1btc, with an average of about 0.25btc each, would give you a good chance of success. If someone dumped 100 btc on you, NXT would be stillborn.
Pouncer
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
October 20, 2013, 02:15:03 AM
 #176

The main issue I see is distributing the coins to enough people.

Agree. Without at least 100 users on start the whole currency is pointless. I would spend collected bitcoins for advertising instead of development of advanced features.

I agree with this 100%. Once the word gets out you run the risk of a few big players sending you large amounts of btc (100+, or even higher). The bonus idea is a good one. With MasterCoin, right at the end in the last few days some big amounts were sent in - 400 btc etc. That could potentially kill this coin.

Maybe you could add a maximum amount people can send you too. Just an idea, to help spread the NXT around more evenly.

I'd say a 100 users is the bare minimum to start. 250 users each having btc amounts under 1btc, with an average of about 0.25btc each, would give you a good chance of success. If someone dumped 100 btc on you, NXT would be stillborn.


What is the difference between a user sending in 1 transaction of 100 BTC compared to the same user sending in 100 transactions of 1 BTC each?

NXTtechdevfund  GPG Key ID: 0x903BC112
cunicula
Hero Member
*****
Offline Offline

Activity: 854
Merit: 1003


Stack-overflow Guru


View Profile
October 20, 2013, 03:28:44 AM
 #177

Valid point.  Will adding a generation delay for novel keys solve this problem?  60 blocks (~1 hour) to wait until someone is able to generate blocks, what do you think?
I don't think that will work.

Suppose I have 0.001% of stake and vast computing power. All I have to do to attack is construct a 60 block private chain and then I can use my computing power to extend this chain to an arbitrary length.

The 60 block hurdle might be enough to prevent atack if it took years to construct. However, it doesn't. In practice, an attack chain will be just marginally slower than a legit chain. This will remain true even if the attacker has only say 0.001% of stake.

Recall that the target halves every second. If 99.999% of stake can conetruct a block in 60 seconds on average, then 0.001% of stake will be able to construct a block in 77 seconds on average. So it will only take about an hour and 15 minutes to execute an PoW based attack with a 60 block delay.

The target falls so quickly that you are relying very heavily on synchronous time in the process.
In your system:
 target = difficulty constant * exp (-0.7t) where t is measured in seconds
A very slight misrrporting of the timestamp offers a tremendous advantage.

I suggest the following modification
target = difficulty constant * exp (-0.7 ln (t))

Under this adjustment, our 0.001% attacker would needs 173 days per attack block instead of 77 seconds.
This is still not enough though.
If we are dealing with a 10% attacker then he would need about 25 minutes per attack block, so with a 60 block delay, he could execute a PoW based attack in a couple of days.

To solve the problem, you also need to prevent users from controlling the seed used to generate the hit entirely.
I think you should assign each satoshi a permanent color. Say the color is indexed by an integer from 1 to 1 billion (1 billion satoshis, right?).
Then the miner generates a unique hit for each satoshi under his control. The hit for each satoshi should be determined by
Hash (satoshi color,  block height)
So over the long run all satoshis are equal in terms of mining power.

I also think you should implement the modified rule for target descent shown above. The target drops much to quickly with time in your current design. Under my modified rule, the target halves with every doubling in waiting time. So it halves between ..., 15 and 30 seconds,30 and 60 seconds, and then halves again between 60 and 120 seconds, and so on


Finally, you need to enforce synchronicity more stringrently than bitcoin. Blocks that are timestamped ahead of user time should be rejected (at least until user time catches up with them). Comparing chains of equivalent length and differing only in the current block, you should have the client choose whichever current block has an earlier timestamp as the correct chain.

The last issue is the lack of any resource cost associated with a failed attack attempt. I'm willing to believe that this is just a theoretical concern (and ignore it). It is very complicated to solve under a pure POS system. You should be prepared, however, for a lot of criticism on this aspect.

BTW are you planning to use centralized checkpoints for each block as in PPC? Please don't. This is a good way of ruining your credibility. If you don't use checkpoints, then you will have a very clear point of differentiation from PPC.

▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
        Quickseller is a scammer and sockpuppet of OGdynasty        [/glow][/size]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
boomboom
Hero Member
*****
Offline Offline

Activity: 689
Merit: 501



View Profile
October 20, 2013, 04:10:26 AM
 #178

The main issue I see is distributing the coins to enough people.

Agree. Without at least 100 users on start the whole currency is pointless. I would spend collected bitcoins for advertising instead of development of advanced features.

I agree with this 100%. Once the word gets out you run the risk of a few big players sending you large amounts of btc (100+, or even higher). The bonus idea is a good one. With MasterCoin, right at the end in the last few days some big amounts were sent in - 400 btc etc. That could potentially kill this coin.

Maybe you could add a maximum amount people can send you too. Just an idea, to help spread the NXT around more evenly.

I'd say a 100 users is the bare minimum to start. 250 users each having btc amounts under 1btc, with an average of about 0.25btc each, would give you a good chance of success. If someone dumped 100 btc on you, NXT would be stillborn.


What is the difference between a user sending in 1 transaction of 100 BTC compared to the same user sending in 100 transactions of 1 BTC each?


The main difference would be the amount of time and hassle required to repeat the procedure 100 times. If the send could somehow be connected to a user profile on this forum, that would limit the number of multiples quite a bit too.

Maybe the dev has another idea. I just think with a POS coin it's best to spread the coins around at the start, and with Mastercoin some big whales joined the party right at the end. Some way to limit excessively large single holdings is a good goal. Once the close time approaches some people might get greedy.
BCNext
Jr. Member
*
Offline Offline

Activity: 56
Merit: 3


View Profile
October 20, 2013, 06:54:57 AM
 #179

Hey, I have a server that could help in bootstrapping the network and some coins. Need my help? :>

Of course, pm me with its IP address or domain name, please.
BCNext
Jr. Member
*
Offline Offline

Activity: 56
Merit: 3


View Profile
October 20, 2013, 08:20:01 AM
 #180

Suppose I have 0.001% of stake and vast computing power. All I have to do to attack is construct a 60 block private chain and then I can use my computing power to extend this chain to an arbitrary length.

Let's suppose you have 10% of stake and an alien's computer stolen from Area 51.  Odds to generate 60 block long chain at the rate of 1 block a minute are very small (something like 1/10000000000000...)  Cumulative difficulty of your branch will be much lower than difficulty of the main chain and it won't be accepted by other peers (you can generate your chain very fast with timestamps far in the future).  You continue and now begin searching for private keys that can give you public keys with hits very close to zero (let's call them attacking accounts).  You have to do a lot of Ed25519 computations (requires much more CPU power than SHA256) but you have an alien's computer and you complete the task within 2 minutes.  Now you have to go to Area 51 again and stole a time machine or wait for a few months (otherwise blocks of your chain won't be accepted due to incorrect timestamps).

Let's think how to counteract the attack.

The first thing that has come to my mind is to extend maturity period from 60 (1 hour) to 1440 blocks (1 day).  This will force you to wait for years and even after that you will not be able to complete the attack because of checkpointing.  I don't really like to wait for 1 day before I start generating blocks, I will think more and may come to another solution.


The 60 block hurdle might be enough to prevent atack if it took years to construct. However, it doesn't. In practice, an attack chain will be just marginally slower than a legit chain. This will remain true even if the attacker has only say 0.001% of stake.

Recall that the target halves every second. If 99.999% of stake can conetruct a block in 60 seconds on average, then 0.001% of stake will be able to construct a block in 77 seconds on average. So it will only take about an hour and 15 minutes to execute an PoW based attack with a 60 block delay.

The target falls so quickly that you are relying very heavily on synchronous time in the process.
In your system:
 target = difficulty constant * exp (-0.7t) where t is measured in seconds
A very slight misrrporting of the timestamp offers a tremendous advantage.

I suggest the following modification
target = difficulty constant * exp (-0.7 ln (t))

Under this adjustment, our 0.001% attacker would needs 173 days per attack block instead of 77 seconds.
This is still not enough though.
If we are dealing with a 10% attacker then he would need about 25 minutes per attack block, so with a 60 block delay, he could execute a PoW based attack in a couple of days.

To solve the problem, you also need to prevent users from controlling the seed used to generate the hit entirely.
I think you should assign each satoshi a permanent color. Say the color is indexed by an integer from 1 to 1 billion (1 billion satoshis, right?).
Then the miner generates a unique hit for each satoshi under his control. The hit for each satoshi should be determined by
Hash (satoshi color,  block height)
So over the long run all satoshis are equal in terms of mining power.

I also think you should implement the modified rule for target descent shown above. The target drops much to quickly with time in your current design. Under my modified rule, the target halves with every doubling in waiting time. So it halves between ..., 15 and 30 seconds,30 and 60 seconds, and then halves again between 60 and 120 seconds, and so on

I'm sorry that I misinformed you.  It's true that the target on the 2-second mark is 2 times bigger than on the 1-second mark, but it's only because each second the target grows by 1/60 of the base target.  On the 3-second mark it will be 3 times bigger than on mark 1, and 1.5 times bigger than on mark 2.

Code:
Target = BaseTarget * TimeSincePreviousBlock / 60


Finally, you need to enforce synchronicity more stringrently than bitcoin. Blocks that are timestamped ahead of user time should be rejected (at least until user time catches up with them). Comparing chains of equivalent length and differing only in the current block, you should have the client choose whichever current block has an earlier timestamp as the correct chain.

It is already implemented, all new blocks must be within +/- 15 seconds.


The last issue is the lack of any resource cost associated with a failed attack attempt. I'm willing to believe that this is just a theoretical concern (and ignore it). It is very complicated to solve under a pure POS system. You should be prepared, however, for a lot of criticism on this aspect.

Is there any other attack except Cunicula attack described above?  That one requires a lot of resources.


BTW are you planning to use centralized checkpoints for each block as in PPC? Please don't. This is a good way of ruining your credibility. If you don't use checkpoints, then you will have a very clear point of differentiation from PPC.

Nxt uses accounts, not inputs/outputs (payment privacy is supposed to be provided via mixing feature).  Each 525949th block (1 year) the blockchain will be shrunk (and checkpointed).
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 146 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!