Bitcoin Forum
March 29, 2024, 12:18:43 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 [1505] 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761519 times)
tk808
Legendary
*
Offline Offline

Activity: 1512
Merit: 1124


Invest in your knowledge


View Profile
February 06, 2014, 03:52:47 AM
 #30081

Is it possible to have scaling transaction fees?


You know, for larger transactions to get hit with more transaction fees? This would be a really nice feature for NXT
Whoever mines the block which ends up containing your transaction will get its fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711714723
Hero Member
*
Offline Offline

Posts: 1711714723

View Profile Personal Message (Offline)

Ignore
1711714723
Reply with quote  #2

1711714723
Report to moderator
1711714723
Hero Member
*
Offline Offline

Posts: 1711714723

View Profile Personal Message (Offline)

Ignore
1711714723
Reply with quote  #2

1711714723
Report to moderator
1711714723
Hero Member
*
Offline Offline

Posts: 1711714723

View Profile Personal Message (Offline)

Ignore
1711714723
Reply with quote  #2

1711714723
Report to moderator
iruu
Full Member
***
Offline Offline

Activity: 148
Merit: 100


View Profile
February 06, 2014, 03:54:54 AM
 #30082

At a minimum you would need to store the account # (64 bits) plus the public key (256 bits) plus the balance (64 bits?) which would be 384 bits or 48 bytes per account.
Account id is a sha of public key. It doesn't need to be stored, except as an optimization.  
Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.  

CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1072


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 06, 2014, 03:57:13 AM
 #30083

Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.  

Am not quite getting this - is your figure of 44721 based upon a "current snapshot" - as I am talking about the theoretical maximum storage required for either 1M accounts or 1B accounts.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 03:59:51 AM
 #30084

At a minimum you would need to store the account # (64 bits) plus the public key (256 bits) plus the balance (64 bits?) which would be 384 bits or 48 bytes per account.
Account id is a sha of public key. It doesn't need to be stored, except as an optimization.  
Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.  

If I'm understanding this right, that means that if an otherwise active account gets a zero balance that carries over the blockchain pruning event, then the public key will be erased from the blockchain?  Or am I misunderstanding?

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
salsacz
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


View Profile
February 06, 2014, 04:03:12 AM
 #30085

Articles writing updates - some topics were assigned in last days (open bounty is up to 3.000 Nxt/good long article)

- Why is pure Proof of Stake in Nxt best solution for cryptocurrencies?

- How can you mine Nxt only with solar energy?

- How could decentralized exchanges change the world? (no Government, no censorship, USA, China...) - + decentralized messaging, DNS

- The 51% Attack - technical details, history of 51% attacks, how it ended, Nxt solution (is Nxt safer than other PoS currencies?) (Ghash's pool is risking Bitcoin's security again with 40% of the network's hashpower and no one is talking about it. Pools of PoW machines with enormous hashpower is Bitcoin's most pressing concern and biggest flaw right now. Nextcoin is the best answer to this. Why is it not being talked about more?)
- Zahlen

- Nxt: gaming friendly currency (vs. Litecoin, a graphic cards killer) - Due to Litecoin's difficulty skyrocketing there is a global shortage of Graphic Cards, which piss off gamers tremendously and drive up the price for grahics cards. NXT solves this. (Uniqueorn's idea, maybe reserved for him..?)

- Nxt + Raspberry (+other similar platforms (Cubietruck)) (can be different articles, also short articles) (0 energy  forging package)

- Transparent Forging (very very technical, history of mining, comparisons)

Shorter articles/essays:

- Why should you invest in Nxt? (/Why should you invest in Nxt long term?)
- bithic
- Damelon
- many free spots

- Why is Nxt so friendly currency?: (i) It *doesn't* have VC capital backing. ii) It *doesn't* have "slick sales guys*. iii) It *does* have smart devs and an increasing following.  iv) It *is* delivering its promises (more or less) on time.) - more about the community, people form all over the world, community funding, decentralized company - a world of free individuals who all believe in Nxt. 1500 pages in Bitcointalk
- bithic

- How Nxt changed my life


Future (short) articles: (now it's to soon):

- Who accepts Nxt as a payment? (+ fee in Nxt vs. Bitcoin vs. fiat (VISA))
- Nxt invites altcoins to host on it's blockchain
- Can be a new internet stored on Nxt's blockchain / DNS system?
- Nxt clients: Damelon

Have you got any idea about some other article? Share it. We would love to have more scientific articles, financial, economical, IT...

Discussion in Topic: Nxt marketing & promotion
https://bitcointalk.org/index.php?topic=412243.0
erik__
Newbie
*
Offline Offline

Activity: 38
Merit: 0


View Profile
February 06, 2014, 04:06:56 AM
 #30086

I have a couple of thoughts to share before I go to work for the night.

First:
as someone who BELIEVES CfB when he says nobody should trust anybody, I believe that asking us all to "trust" a mandatory update to 0.5.12, followed by a miserable admission of error and a mandatory update to v0.6.0 a few hours later – all without an explanation of the issue – is a violation.  I have stopped my server and will not restart it until the nature of the "critical bug", and its fix, are disclosed.

To a certain extent if the lead developer issues a release and says it's critical we have no choice but to trust him.  But, outside developers can and should perform their own independent audits of new releases to see if something suspicious is done and raise the alarm if need be.

iruu
Full Member
***
Offline Offline

Activity: 148
Merit: 100


View Profile
February 06, 2014, 04:16:08 AM
Last edit: February 06, 2014, 04:33:17 AM by iruu
 #30087

If I'm understanding this right, that means that if an otherwise active account gets a zero balance that carries over the blockchain pruning event, then the public key will be erased from the blockchain?  Or am I misunderstanding?
I don't think doing this during blockchain pruning is a good idea. Just sent everything below 1 NXT as a fee, automatically. Don't accept transactions to other accounts if their balance would be lower than 1 NXT after this. This way, it's not possible to have lower balance.  
Blockchain and balance sheet should be equivalent. Blockchain is an incremental update of balances, balance sheet is a consolidated version.  

It's possible to accept lower balances, but at 0.01 NXT minimum balance maximum theoretical balance sheet size is 3.2TB.

Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.  

Am not quite getting this - is your figure of 44721 based upon a "current snapshot" - as I am talking about the theoretical maximum storage required for either 1M accounts or 1B accounts.

Actually it's 44720, sorry, didn't notice the rounding.
There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
For smallest increase 0.01, it's 447114 different balances possible at the same time, still with 1 NXT minimum balance.  

^[GS]^
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
February 06, 2014, 04:17:15 AM
 #30088

Fee voting tally google doc spreadsheet.  Please check your vote and PM me if I made a mistake.

https://docs.google.com/spreadsheet/ccc?key=0Akjrt0LTBXgcdFFkSGMwXzd4Q2NPU21yU2NOYWVldlE&usp=sharing

fix me! only 1 to 0.1!

I never said 0.3333 Tongue
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1072


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 06, 2014, 04:23:47 AM
 #30089

There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.

Okay - I sort of get it now - but I'm not sure if that's going to be so useful for data storage as you will need to index on "account" not on "balance".

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
joefox
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile WWW
February 06, 2014, 04:24:33 AM
 #30090

To a certain extent if the lead developer issues a release and says it's critical we have no choice but to trust him.  But, outside developers can and should perform their own independent audits of new releases to see if something suspicious is done and raise the alarm if need be.

Most Nxt users are not "developers", so while I take your point, I also suggest that most people are being asked to update software without being able to understand OR verify the reason for the update.  It's the software-developer equivalent of "trust me. Just do it."

It's hypocritical to build a decentralized system that is supposed to be trustless, and then ask "untrusted" members of that community to "trust" that they should install new software and not ask questions of the "untrusted" people who issue the order.

You can do your own thing, of course, but I won't give.  I'm not gonna jump off a bridge just because Jean-Luc or CfB says so.  What they've done is bad, and they should feel bad.  When I get an explanation, I'll update my software.

I admin the Nxt Wiki at http://wiki.nxtcrypto.org/ Please support my work by donating to Nxt account #1234567740944417915
pandaisftw
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
February 06, 2014, 04:29:54 AM
 #30091

To a certain extent if the lead developer issues a release and says it's critical we have no choice but to trust him.  But, outside developers can and should perform their own independent audits of new releases to see if something suspicious is done and raise the alarm if need be.

Most Nxt users are not "developers", so while I take your point, I also suggest that most people are being asked to update software without being able to understand OR verify the reason for the update.  It's the software-developer equivalent of "trust me. Just do it."

It's hypocritical to build a decentralized system that is supposed to be trustless, and then ask "untrusted" members of that community to "trust" that they should install new software and not ask questions of the "untrusted" people who issue the order.

You can do your own thing, of course, but I won't give.  I'm not gonna jump off a bridge just because Jean-Luc or CfB says so.  What they've done is bad, and they should feel bad.  When I get an explanation, I'll update my software.

It is unfortunate they had to do it this way, but if they said it was urgent, then it most likely is. The fact that both of them (and I suppose the implicit approval of BCNext) approved it makes it not as bad. C-f-b did say he would disclose what it was, but I'm sure how won't do that until a large majority of nodes have upgraded to 0.6.0.

NXT: 13095091276527367030
rickyjames
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
February 06, 2014, 04:34:03 AM
 #30092



If we can recast a genesis block every 20th block as part of the routine operation of the NXT blockchain, we have accomplished something very, very special - a self limiting blockchain that grows very slowly.
A blockchain needs to be as long as longest possible fork, at least. I don't know, half a day? Definitely not 20 blocks.  

1440 blocks is the limit for blockchain reorganization if I'm remembering correctly.  So it would have to be just beyond there.


Let's call it 1500 blocks between pruning / re-genesis to be on the safe side.  1500 minutes = 25 hours.  So for a testnet to generate three genesis blocks during its run to prove that's a routine thing, it needs to go 75 hours, or three days and three hours.  

Total number of fake transactions that need to be broadcast during a NXT 3+ day pruning 1000 TPS testnet demo run are 3*1500*60*1000 = 270 million.  At 128 bytes per transaction, that's  just under 35 GB.  SO the block chain grows by say 12GB between pruning and re-genesis.   The Bitcoin blockchain is currently at just under 14 GB:  https://blockchain.info/charts/blocks-size .  

So with the proposed 1000 TPS testbed with re-genesis every 1500 blocks we are saying that when NXT gets to the current Bitcoin blockchain size, we do something about it.  They don't.  Victory NXT.  This alone make the project worth doing.

So does the requirement to let a 1000 TPS blockchain go over 1440 blocks / 10 GB in size to avoid forks mean that Raspberry Pis and smartphones are now excluded from the 1000 TPS testbed?  Or is there a trick we can use to keep them along for the ride?  Please discuss.

And somebody please tell me how you booby trap a genesis block so we've got to wait for source code release to start on this?
Zahlen
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
February 06, 2014, 04:35:55 AM
Last edit: February 06, 2014, 05:04:32 AM by Zahlen
 #30093

(Sorry about all the names mentioned. But I have to be concrete.)

To NxtChg:

I obviously can’t stay in a community where four words and a stupid smiley makes somebody wish you death

Guess you meant this:

Quote from: opticalcarrier
No he got it right I change my mind on you where previously I said you should not go away now I think you should go play in traffic seriously please sell all your next and just get the f*** out of here

His intent wasn't to wish you death. It was just to rage at you, and he chose mean words in the heat of things. Not saying that's acceptable, but saying you might be making too much of it.

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.

I think a cohesive community is great. But a community that doesn't disagree is simply homogeneous, and imo consequently brittle. A truly robust, cohesive community should be able to handle disagreements and work past them.


As xyzzyx mentioned in the other thread, you can disagree without being disagreeable. I'd add that instead of just debate (in particular angry debate), also try for discussion and dialetic instead. Explain where you're coming from, don't assume that the other party has the same knowledge, prior experience, insight and perspective as you. This paragraph applies to everyone, not just one person.

For instance, you and jl777 keep butting heads hard. James tends to take an idea and see how far he can go with it, that's his strength. And also I think with too narrow focus on certain objectives  (1 instruction!) to the exclusion of other considerations, that's his weakness, and where he'd like us to come in and help fill the gaps. I've always found James open to reasoning.

NxtChg, I think if you had presented this to James earlier (and without a loaded tone), your discussion could have gone differently.


In discussions, I've found that it helps to quote just those points that you're addressing. This lets you and the other party be clear about what exactly each of you are referring to, instead of trying to respond to an entire long post all at once and possibly (likely imo) building on more and more different assumptions on both sides. (This will also cut down on quote pyramid clutter. But I'm tired of pressing this issue.)

This post applies to all of us, not just the folks I've mentioned in it.


NxtChg, we want you here. Please stay. Smiley

Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
February 06, 2014, 04:37:41 AM
 #30094

To a certain extent if the lead developer issues a release and says it's critical we have no choice but to trust him.  But, outside developers can and should perform their own independent audits of new releases to see if something suspicious is done and raise the alarm if need be.

Most Nxt users are not "developers", so while I take your point, I also suggest that most people are being asked to update software without being able to understand OR verify the reason for the update.  It's the software-developer equivalent of "trust me. Just do it."

There is no such thing as  zero trust. You are using operating system, and you trust it's not logging everything you type and sending it somewhere. You trust the software developers of your web browser.  Even if you are using open source software, how would you know if the official binary is based on the released source code? (unless you build your own binaries after going through the source line by line).

Zero trust doesn't exist.

In this case, everyone who is a Nxt user is trusting the developers. There is simply no choice.

There maybe reasons not to publish the exploits until most users have upgraded.

Nomi, Shan, Adnan, Noshi, Nxt, Adn Khn
NXT-GZYP-FMRT-FQ9K-3YQGS
https://github.com/Lafihh/encryptiontest
rickyjames
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
February 06, 2014, 04:38:17 AM
 #30095


NxtChg, we want you here. Please stay. Smiley


+1
bithic
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
February 06, 2014, 04:39:48 AM
 #30096


NxtChg, we want you here. Please stay. Smiley


+1

+2. Good post Zahlen. Better PM him in case he's stopped reading this thread.
msin
Legendary
*
Offline Offline

Activity: 1470
Merit: 1004


View Profile
February 06, 2014, 04:43:17 AM
 #30097


NxtChg, we want you here. Please stay. Smiley


+1

+2. Good post Zahlen. Better PM him in case he's stopped reading this thread.

+3
joefox
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile WWW
February 06, 2014, 04:44:53 AM
 #30098

Zero trust doesn't exist.

In this case, everyone who is a Nxt user is trusting the developers. There is simply no choice.

There maybe reasons not to publish the exploits until most users have upgraded.

Fair point.

I updated the software change log on the wiki tonight, and the "change log" for this version and the last one really bugged me.  Just compare what was said about these two versions to almost ANY previous version and you'll see what I mean.

Jean-Luc and CfB have earned a fair bit of trust from me since December.... but based on the information around these two updates, I've stepped slightly backwards from my previous trust level.

I admin the Nxt Wiki at http://wiki.nxtcrypto.org/ Please support my work by donating to Nxt account #1234567740944417915
iruu
Full Member
***
Offline Offline

Activity: 148
Merit: 100


View Profile
February 06, 2014, 04:49:17 AM
 #30099

Okay - I sort of get it now - but I'm not sure if that's going to be so useful for data storage as you will need to index on "account" not on "balance".
Well, that's the minimum storage version.
The performance version would be a list of public keys sorted by their account id with their balance id, which would take 34.34GB. This would have search performance lg(number of accounts), very fast.  

xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 06, 2014, 04:50:55 AM
Last edit: February 06, 2014, 05:02:53 AM by xyzzyx
 #30100

Zero trust doesn't exist.

In this case, everyone who is a Nxt user is trusting the developers. There is simply no choice.

There maybe reasons not to publish the exploits until most users have upgraded.

Fair point.

I updated the software change log on the wiki tonight, and the "change log" for this version and the last one really bugged me.  Just compare what was said about these two versions to almost ANY previous version and you'll see what I mean.

Jean-Luc and CfB have earned a fair bit of trust from me since December.... but based on the information around these two updates, I've stepped slightly backwards from my previous trust level.

Reading between the lines of their posts this is what I get: there's an active exploit in the wild right now.  

Upgrade.  Seriously.


"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
Pages: « 1 ... 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 [1505] 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 ... 2557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!