Bitcoin Forum
September 15, 2019, 11:12:46 PM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 [1690] 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 ... 2567 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2756160 times)
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
February 14, 2014, 08:13:40 PM
 #33781

Not, if the runtime for calculating a sig is dependent on the number of bits of the payload.

It is a common misconception that basic operations are in O(1), but that's wrong. Even addition and multiplication of larger numbers take longer than of smaller numbers. The same hodls for sig function.

I like the conceptual idea of having set-based transactions because set-based thinking is one of the principle of modern computer science.

What I was trying to explain to you was that you should not make not unproven statements.
Show me the runtime complexity of the sig function in terms of payload length and we'll see.

NRS signs SHA256 of a message.

1 signature takes 100 times more CPU ticks than SHA256(32_random_bytes). Signing of a transaction that is 100 times longer ~ 2 ordinary signatures.
1568589166
Hero Member
*
Offline Offline

Posts: 1568589166

View Profile Personal Message (Offline)

Ignore
1568589166
Reply with quote  #2

1568589166
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
mcjavar
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
February 14, 2014, 08:14:32 PM
 #33782

What does this mean?


[2014-02-14 10:39:40.346] DEBUG: Will pop block 5073332198957728923 at height 66148
[2014-02-14 10:39:40.347] DEBUG: Will pop block 8348856438008341233 at height 66147
[2014-02-14 10:39:40.348] DEBUG: Reversal of alias assignment not supported
[2014-02-14 10:39:40.348] DEBUG: Popping off last block not possible, will do a rescan
[2014-02-14 10:39:40.349] Re-scanning blockchain...
[2014-02-14 10:39:54.734] ...Done
[2014-02-14 10:39:54.737] DEBUG: Generate block failed: Previous block id doesn't match


Jean-Luc?
greyw00lf
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
February 14, 2014, 08:16:07 PM
 #33783

please, can i get some coin?  my nxt address is 1954727322887273577

thanks
im convinced in this currency
Hi ErosLp, you can use the faucet at http://nxtra.org/faucet to get your first Nxt
or take a look at http://mynxt.org/#nxt
or use exchanges to buy some Nxt: http://mynxt.org/#exchanges

jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 14, 2014, 08:20:18 PM
 #33784

Depends which cost function you take into consideration. The size of the block part occupied by a multi-transaction would still be O(n) as are n transaction. So, yes, it could be cheaper by a factor of 2 or so.

A key thing that Nxt *has* over its rivals is fast txs. If I have a tx with 100 outputs and 1 sig vs. 100 outputs and 100 sigs then the latter is going to be slower both in terms of data size and sig verification.

So I think that Nxt should allow such more compact txs in order to provide the "leanest and meanest" tx system in the crypto currency world.

Agreed. We might as well be the best in all areas.

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
greyw00lf
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
February 14, 2014, 08:22:03 PM
 #33785

@JL
Code:
[2014-02-14 18:23:55.255] Database is at level 13
[2014-02-14 18:23:55.267] DEBUG: Will apply sql:
ALTER TABLE block DROP COLUMN IF EXISTS index
[2014-02-14 18:26:26.984] DEBUG: Will apply sql:
ALTER TABLE transaction DROP COLUMN IF EXISTS index
[2014-02-14 18:33:32.807] Updated database is at level 15

Didn't the additional indexes help?


Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?

Raspis do have a tough time doing that, crashes 1-3 each time, must be restarted, takes severla hours in total...
I don't have problems downloading the whole blockchain with my RPi (not overclocked), no crashes, no restarts. It takes hours... hmm yes maybe 1-2 hours, but you don't have to do that on every update. The last time i did was when i switched to 0.7.2. From then i always copied the db to my new nxt-folder.


No, no. Smiley It does not. Just overclock it at medium level. Works like a charm for me.

And yes, you can re-use the db of 0.7.4.

In fact the nxt.log above shows the migration from 0.7.4 to 0.7.5.
I didn't overclock mine. To what CPU-rate did you overclock it? Do you use some kind of cooling? My RPi is just in an ordinary plastic-case, no cooling at all...


jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 14, 2014, 08:26:36 PM
 #33786


P.S. I am trying to make sure that even after NXT goes above $1000 we can still buy a lollipop at a precise price.

even if Nxt goes to $1000, 0.00001 would be 1 cent

Too many decimal points bring confusion.
How much does a single crypto cost? One that is .0000000013 BTC? I just want to be able to not have to worry about bundling very small valued things so we dont have the quantization problem.

The GUI can hide the extra precision. I am not talking about display. I am talking about what the low level protocol supports.

I am also not talking about reducing the fee to .00000001 NXT. The fee should be reduced an order of magnitude at a time as we find that it is a problem.

Reworking the code to add precision is the time where we can figure out how to add the most digits without adding too much overhead. We dont have to use or display that precision, but if we can get it essentially for free, why not?

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Jean-Luc
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250



View Profile WWW
February 14, 2014, 08:28:01 PM
 #33787

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?
Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

lead Nxt developer, gpg key id: 0x811D6940E1E4240C
Nxt blockchain platform | Ardor blockchain platform | Ignis ICO
Jean-Luc
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250



View Profile WWW
February 14, 2014, 08:30:49 PM
 #33788

What does this mean?


[2014-02-14 10:39:40.346] DEBUG: Will pop block 5073332198957728923 at height 66148
[2014-02-14 10:39:40.347] DEBUG: Will pop block 8348856438008341233 at height 66147
[2014-02-14 10:39:40.348] DEBUG: Reversal of alias assignment not supported
[2014-02-14 10:39:40.348] DEBUG: Popping off last block not possible, will do a rescan
[2014-02-14 10:39:40.349] Re-scanning blockchain...
[2014-02-14 10:39:54.734] ...Done
[2014-02-14 10:39:54.737] DEBUG: Generate block failed: Previous block id doesn't match

This is all normal, works as intended. It is telling you exactly what is happening - popping off a block, doing a rescan because alias assignment cannot be simply undone in a pop-off. The block generation attempt failed because in the meantime another block arrived and was accepted.

lead Nxt developer, gpg key id: 0x811D6940E1E4240C
Nxt blockchain platform | Ardor blockchain platform | Ignis ICO
l8orre
Legendary
*
Offline Offline

Activity: 1066
Merit: 1002


View Profile
February 14, 2014, 08:31:06 PM
 #33789

Thanks! I am reluctant about the overclocking, but I run it with -856xmx ...

What does -856xmx do?

It is the memory available to the jvm, I quoted it wrong:

ps -ax
 2040 ?        SNl   61:45 /usr/bin/java -Xms128m -Xmx856m -jar start.jar STOP.PORT=7873 STOP.KEY=0815


-Xms128m is the minimum that is reserved at the start, and -Xmx856m is the maximum it can have, in megabytes. I often had crashes with a maximum smaller 450MB, but with giving it almost all the memory, it runs quite good.

Except that dl'ing the whole blockcahin is quite some venture.
l8orre
Legendary
*
Offline Offline

Activity: 1066
Merit: 1002


View Profile
February 14, 2014, 08:35:34 PM
 #33790

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?
Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

once the blockchain is complete 0.7.4 is running quite smoothly at 1-3% cpu, and given lots of ram:

top
                                                              
 2040 pi        26   6  993m 385m 2768 S   1,0 88,0  61:54.85 java                                                                      
 3318 pi        20   0  4880 1324  976 R   1,0  0,3   0:01.18 top        

I think also the blockchain download was faster with 0.7.4, but I can't really tell, because I did not monitor the dl all the time ...
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
February 14, 2014, 08:36:42 PM
 #33791

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?
Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

What exactly do you mean by performance?

1) startup is slow as always. Especially these migrations

2) running is as good as always. Does not go above 5%.

3) RAM consumption is 1% lower. Still 87% of total memory.
l8orre
Legendary
*
Offline Offline

Activity: 1066
Merit: 1002


View Profile
February 14, 2014, 08:38:00 PM
 #33792

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?
Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

What exactly do you mean by performance?

1) startup is slow as always. Especially these migrations

2) running is as good as always. Does not go above 5%.

3) RAM consumption is 1% lower.

yes, which is why having the option of using the nxt_db is quite helpful
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
February 14, 2014, 08:39:53 PM
 #33793

Not, if the runtime for calculating a sig is dependent on the number of bits of the payload.

It is a common misconception that basic operations are in O(1), but that's wrong. Even addition and multiplication of larger numbers take longer than of smaller numbers. The same hodls for sig function.

I like the conceptual idea of having set-based transactions because set-based thinking is one of the principle of modern computer science.

What I was trying to explain to you was that you should not make not unproven statements.
Show me the runtime complexity of the sig function in terms of payload length and we'll see.

NRS signs SHA256 of a message.

1 signature takes 100 times more CPU ticks than SHA256(32_random_bytes). Signing of a transaction that is 100 times longer ~ 2 ordinary signatures.

Not sure, I got it.

The runtime complexity is still O(n)? But the factory in between is 100? (n = number of bits)
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
February 14, 2014, 08:41:02 PM
 #33794

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?
Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

What exactly do you mean by performance?

1) startup is slow as always. Especially these migrations

2) running is as good as always. Does not go above 5%.

3) RAM consumption is 1% lower. Still 87% of total memory.

yes, which is why having the option of using the nxt_db is quite helpful


Why is that? Or maybe, I didn't understand what you mean.
l8orre
Legendary
*
Offline Offline

Activity: 1066
Merit: 1002


View Profile
February 14, 2014, 08:43:50 PM
 #33795

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?
Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

What exactly do you mean by performance?

1) startup is slow as always. Especially these migrations

2) running is as good as always. Does not go above 5%.

3) RAM consumption is 1% lower.

yes, which is why having the option of using the nxt_db is quite helpful


Why is that? Or maybe, I didn't understand what you mean.

when you update, you just dump the old nxt_db directory into the nxt_db in the unzip directory of the new version, and the blockchain won't be downloaded -just as with before, when you could just dump the blocks.nrs and transactions.nrs into the new version.
only then it would crash very often, and now with sql it hopefully won't.

At least that's what I understand from it.
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
February 14, 2014, 08:48:43 PM
 #33796

when you update, you just dump the old nxt_db directory into the nxt_db in the unzip directory of the new version, and the blockchain won't be downloaded -just as with before, when you could just dump the blocks.nrs and transactions.nrs into the new version.
only then it would crash very often, and now with sql it hopefully won't.

At least that's what I understand from it.


Well, I see. I don't think we were talking about the 'manual performance of upgrading' but the runtime performance, though.

But, you are right. That's the idea of having a database which is able to handle transactions, rollbacks, caching, indexing etc. at once. Much better than inventing your own serialization format. +1
mcjavar
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
February 14, 2014, 08:50:11 PM
 #33797

What does this mean?


[2014-02-14 10:39:40.346] DEBUG: Will pop block 5073332198957728923 at height 66148
[2014-02-14 10:39:40.347] DEBUG: Will pop block 8348856438008341233 at height 66147
[2014-02-14 10:39:40.348] DEBUG: Reversal of alias assignment not supported
[2014-02-14 10:39:40.348] DEBUG: Popping off last block not possible, will do a rescan
[2014-02-14 10:39:40.349] Re-scanning blockchain...
[2014-02-14 10:39:54.734] ...Done
[2014-02-14 10:39:54.737] DEBUG: Generate block failed: Previous block id doesn't match

This is all normal, works as intended. It is telling you exactly what is happening - popping off a block, doing a rescan because alias assignment cannot be simply undone in a pop-off. The block generation attempt failed because in the meantime another block arrived and was accepted.


Alias assignment being undone? I didn´t touch the client when this message came.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
February 14, 2014, 08:55:54 PM
 #33798

Not, if the runtime for calculating a sig is dependent on the number of bits of the payload.

It is a common misconception that basic operations are in O(1), but that's wrong. Even addition and multiplication of larger numbers take longer than of smaller numbers. The same hodls for sig function.

I like the conceptual idea of having set-based transactions because set-based thinking is one of the principle of modern computer science.

What I was trying to explain to you was that you should not make not unproven statements.
Show me the runtime complexity of the sig function in terms of payload length and we'll see.

NRS signs SHA256 of a message.

1 signature takes 100 times more CPU ticks than SHA256(32_random_bytes). Signing of a transaction that is 100 times longer ~ 2 ordinary signatures.

Not sure, I got it.

The runtime complexity is still O(n)? But the factory in between is 100? (n = number of bits)

Complexity of signing is O(1).
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 14, 2014, 08:56:50 PM
 #33799

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?
Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?
Does this mean that we are actually generating checkpoint files on all the nodes all the time? If so, how much work would it be to have newly installed nodes query for the most recent db files and start with that, instead of redownloading the entire blockchain. Of course, must be peer verified checksums, etc.

How fast does the DB grow at 1000TPS?


http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
February 14, 2014, 08:57:06 PM
 #33800

Not, if the runtime for calculating a sig is dependent on the number of bits of the payload.

It is a common misconception that basic operations are in O(1), but that's wrong. Even addition and multiplication of larger numbers take longer than of smaller numbers. The same hodls for sig function.

I like the conceptual idea of having set-based transactions because set-based thinking is one of the principle of modern computer science.

What I was trying to explain to you was that you should not make not unproven statements.
Show me the runtime complexity of the sig function in terms of payload length and we'll see.

NRS signs SHA256 of a message.

1 signature takes 100 times more CPU ticks than SHA256(32_random_bytes). Signing of a transaction that is 100 times longer ~ 2 ordinary signatures.

Not sure, I got it.

The runtime complexity is still O(n)? But the factory in between is 100? (n = number of bits)

Complexity of signing is O(1).

That is plain wrong. The more bits you have to sign the longer signing takes. The question is: how long in terms of the input length.
Pages: « 1 ... 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 [1690] 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 ... 2567 »
  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!