Nxt successfully implemented Prunable Data and it has been on the main net for many months now, contributing to reducing blockchain bloat of the Nxt blockchain. So thread is now locked.
Thanks for everyone who helped out
Topic: [Nxt] Implements Blockchain Pruning (Read 1399 times)
This thread was to help test and raise awareness of blockchain pruning on the Nxt testnet.
Nxt successfully implemented Prunable Data and it has been on the main net for many months now, contributing to reducing blockchain bloat of the Nxt blockchain. So thread is now locked.
Thanks for everyone who helped out
Nxt successfully implemented Prunable Data and it has been on the main net for many months now, contributing to reducing blockchain bloat of the Nxt blockchain. So thread is now locked.
Thanks for everyone who helped out
Anyone looking to trial Nxt unreleased features can do so now. There is a call for non technical users to test the testnet; your uncle, your mother your boyfriend.. everyone needs to give it a try.
https://nxtforum.org/general-discussion/%28core%29-release-or-not-release/
Using the testnet it easy (they designed it that way )
What is testnet? It is a play area for new features to be trialled and broken before going on the mainnet that we all use otherwise. It looks the same, works the same as you are used to but you get to play with the newest features before they are released
Things beginners need to know:
1) Don't use your mainnet passwords on the testnet.
2) Do not use your mainnet passwords on the testnet. Create new testnet accounts you only use on testnet, do this and you will be completely safe.
3) Put the testnet client folder in a different place to you mainnet client folder. Cos you can't have two 'nxt' folders in the same place (stop laughing please)
4) You need to edit one file. No programming skills required, just basic typing skills. Go in to the folder nxt > conf > and open nxt.default_properties in notepad.
Where it says nxt.isTestnet=false change it to nxt.isTestnet=true This tells the client to connect to testnet and not mainnet. Save the file and close.
5) This is the link to the testnet client, you can't use the mainnet one: http://localhost:6876/index.html
6) Once you have the testnet client running with a brand new testnet account set up, post you account ID here: https://nxtforum.org/testnet/some-testnxt-to-test-asset-exchange/
7) By doing step 6), you will shortly be sent some FREE TestNXT! (that aren't worth anything). So you will then have the ammunition to...
Personally, I am going to create an MSCurrency and use it as tokens in a vote (yes, you can vote with stuff other than NXT ). If you want to take part, please post your testnet account here and I will send you a few tokens.
If I have convinced you to give it a whirl (what is the worst that could happen?), the latest testnet client is 1.5.8e and you can download it from: https://nxtforum.org/nrs-releases/nrs-v1-5-8e/
If this post is scary and frightening (understandable), then don't worry. Just ignore it and make sure you have upgraded the latest stable mainnet client (at time of writing NRS v1.4.18)
Please post any questions and I will find someone who can answer them
https://nxtforum.org/general-discussion/%28core%29-release-or-not-release/
Using the testnet it easy (they designed it that way
) What is testnet? It is a play area for new features to be trialled and broken before going on the mainnet that we all use otherwise. It looks the same, works the same as you are used to but you get to play with the newest features before they are released
Things beginners need to know:
1) Don't use your mainnet passwords on the testnet.
2) Do not use your mainnet passwords on the testnet. Create new testnet accounts you only use on testnet, do this and you will be completely safe.
3) Put the testnet client folder in a different place to you mainnet client folder. Cos you can't have two 'nxt' folders in the same place (stop laughing please)
4) You need to edit one file. No programming skills required, just basic typing skills. Go in to the folder nxt > conf > and open nxt.default_properties in notepad.
Where it says nxt.isTestnet=false change it to nxt.isTestnet=true This tells the client to connect to testnet and not mainnet. Save the file and close.
5) This is the link to the testnet client, you can't use the mainnet one: http://localhost:6876/index.html
6) Once you have the testnet client running with a brand new testnet account set up, post you account ID here: https://nxtforum.org/testnet/some-testnxt-to-test-asset-exchange/
7) By doing step 6), you will shortly be sent some FREE TestNXT! (that aren't worth anything). So you will then have the ammunition to...
- Have a vote on the world's best bobsleigh team
- Phase a transaction to yourself to stop you spending your pocket money until next week
- Play with the various plugins that aren't available on mainnet yet, like NxtBubble everyone has been losing their minds over recently. Play for free
- and more
Personally, I am going to create an MSCurrency and use it as tokens in a vote (yes, you can vote with stuff other than NXT
). If you want to take part, please post your testnet account here and I will send you a few tokens.If I have convinced you to give it a whirl (what is the worst that could happen?), the latest testnet client is 1.5.8e and you can download it from: https://nxtforum.org/nrs-releases/nrs-v1-5-8e/
If this post is scary and frightening (understandable), then don't worry. Just ignore it and make sure you have upgraded the latest stable mainnet client (at time of writing NRS v1.4.18)
Please post any questions and I will find someone who can answer them
No transaction pruning based on Merkele trees?
I think the long term plan might be described as "rolling re-genesis".
The states of all objects in Nxt are recorded at a given block and the clients then use this as the 'new genesis'. This is done every x blocks automatically. There are very few concrete details about that element so far so don't quote me
Ask Chuckone on Nxtforum. Most likely, as with message pruning above, there will be services set up to store everything (not just the hashes) and charge others to retrieve the pruned data if required. Everyone else will have the hashes of the data so they can confirm that the date provided matches the hash of the tx they have in their blockchain.
No transaction pruning based on Merkele trees?
NXT is the trailblazer of decentralized technology!
that is pretty cool
New APIs added and tweaks made to pruning. Plain and encrypted messages now prunable in the client UI.
Source: https://nxtforum.org/nrs-releases/nrs-v1-5-2e
Source: https://nxtforum.org/nrs-releases/nrs-v1-5-2e
Release 1.5.2e
*snip*
This is a development release for testing only. Source code is not provided.
Change log:
This is an experimental release. It is a required update for all testnet nodes,
but is also possible to run on main net.
Added getAllPrunableMessages API, returning all currently available prunable
messages in reverse block timestamp order.
Added verifyPrunableMessage API, which can be used to verify that a prunable
message obtained from another node (a service provider) matches the hash found
in the blockchain, i.e. has not been tampered with.
Show maxPrunableLifetime setting in getState and getBlockchainStatus. Show
current number of prunable messages in getState.
Changing the nxt.maxPrunableLifetime property now also affects existing
prunable messages (next time pruning is run), as transaction timestamps instead
of expiration timestamps are now used.
Reverted DGS goods delivery maximum size to 10 kbytes, same as in 1.4. For
goods of a larger size, a prunable encrypted message should be included in the
delivery instead.
Removed core restriction on 28 byte minimum prunable message length, this will
be checked by the client UI only.
Added nxt.includeExpiredPrunables property, to be able to force to still
include the prunable parts in the returned transaction JSON, even if expired,
as long as they are still available. Can be used to force an archival node to
always return those, thus allowing another archival node that feeds from it to
also get all of them.
Limit the number of unconfirmed transactions that can be brought in memory to
nxt.maxUnconfirmedTransactions, no limit by default. If set, transactions with
lowest fee/size ratio are dropped from the unconfirmed pool first. The ordering
is same as the one used when selecting which transactions to include in a new
block.
Added requeueUnconfirmedTransactions debug API.
Added support for uncompressed non-prunable encrypted messages and encrypted
to self messages, as a new appendix version, to avoid the need to specify the
compression status as a request parameter when reading them.
Added setLogging API, to allow changing log levels without having to restart
the server.
Added eventRegister and eventWait APIs, to be used for registering listeners
and waiting for server events instead of polling.
Changed the parameters accepted by broadcastTransaction. The prunable parts
must be submitted either in the transactionJSON, or, if using transactionBytes,
in a new prunableAttachmentJSON parameter, which has the same format as the
transaction attachment json. The prunableAttachmentJSON is also returned by
the signTransaction and getTransactionBytes APIs now.
Added support for prunable plain and encrypted messages in the client UI.
Added optional buyer parameter to getDGSGoodsPurchases API.
Voting system UI improvements and bugfixes.
*snip*
This is a development release for testing only. Source code is not provided.
Change log:
This is an experimental release. It is a required update for all testnet nodes,
but is also possible to run on main net.
Added getAllPrunableMessages API, returning all currently available prunable
messages in reverse block timestamp order.
Added verifyPrunableMessage API, which can be used to verify that a prunable
message obtained from another node (a service provider) matches the hash found
in the blockchain, i.e. has not been tampered with.
Show maxPrunableLifetime setting in getState and getBlockchainStatus. Show
current number of prunable messages in getState.
Changing the nxt.maxPrunableLifetime property now also affects existing
prunable messages (next time pruning is run), as transaction timestamps instead
of expiration timestamps are now used.
Reverted DGS goods delivery maximum size to 10 kbytes, same as in 1.4. For
goods of a larger size, a prunable encrypted message should be included in the
delivery instead.
Removed core restriction on 28 byte minimum prunable message length, this will
be checked by the client UI only.
Added nxt.includeExpiredPrunables property, to be able to force to still
include the prunable parts in the returned transaction JSON, even if expired,
as long as they are still available. Can be used to force an archival node to
always return those, thus allowing another archival node that feeds from it to
also get all of them.
Limit the number of unconfirmed transactions that can be brought in memory to
nxt.maxUnconfirmedTransactions, no limit by default. If set, transactions with
lowest fee/size ratio are dropped from the unconfirmed pool first. The ordering
is same as the one used when selecting which transactions to include in a new
block.
Added requeueUnconfirmedTransactions debug API.
Added support for uncompressed non-prunable encrypted messages and encrypted
to self messages, as a new appendix version, to avoid the need to specify the
compression status as a request parameter when reading them.
Added setLogging API, to allow changing log levels without having to restart
the server.
Added eventRegister and eventWait APIs, to be used for registering listeners
and waiting for server events instead of polling.
Changed the parameters accepted by broadcastTransaction. The prunable parts
must be submitted either in the transactionJSON, or, if using transactionBytes,
in a new prunableAttachmentJSON parameter, which has the same format as the
transaction attachment json. The prunableAttachmentJSON is also returned by
the signTransaction and getTransactionBytes APIs now.
Added support for prunable plain and encrypted messages in the client UI.
Added optional buyer parameter to getDGSGoodsPurchases API.
Voting system UI improvements and bugfixes.
Great work guys 
On a long enough timeline and given enough adoption, is there a way to prune older transactions themselves and still maintain a secure blockchain?
On a long enough timeline and given enough adoption, is there a way to prune older transactions themselves and still maintain a secure blockchain?
There is a method planned for that too, this is just the first step.
sounds great, the blockchain of bitcoin is too large now, even the nxt block Chian is a little big, it is good to reduce the size of block chain.
Great work guys
On a long enough timeline and given enough adoption, is there a way to prune older transactions themselves and still maintain a secure blockchain?
On a long enough timeline and given enough adoption, is there a way to prune older transactions themselves and still maintain a secure blockchain?
Jump to: