Cool. Parallel chains, here we come.
Dont get too excited, I said in essence, but strictly speaking it is not parallel chains. I'm still looking forward to whatever you have in mind.
Topic: NXT :: descendant of Bitcoin - Updated Information - page 588. (Read 2761626 times)
I'm still looking forward to whatever you have in mind.
I have made an internal proposal to the NXTcash team using the latest source code that will allow us to make a release that can be considered for mainnet use. Not sure how long it will take as I will need to start and finish Nodecoin 2.0 to fully implement the proposed NXTcash solution, not to mention a fair amount of work in the client code.
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Sounds like you're talking about using another chain for the zero-knowledge proofs and putting the hash (pointer) of the ZK block in the Nxt blockchain via AM, effectively using the PoS of Nxt to secure the second chain, no?
James
Cool. Parallel chains, here we come.
I agree with you on needing to keep the cost low and using volume to drive the value of NXT. I can't help but wonder about the server costs and the risk of holding the other currencies. This may sound kinda sharkish but would it be possible to use the holding account to provide for the cost of the server? If there were enough banked in the holding account to cover withdraws and to make loans and charge interest?
For example, if there are 1000 people with money in the holding account it would be very unlikely that they would all want to withdraw at the same time. Knowing this you could safely lend a portion of the holding account out at interest to cover the cost of the server expense, and maybe bank some of the interest for insurance on the holding account. I don't mean to make a profit, as I understand your reasoning in wanting to provide the service for the worlds benefit, but economics is economics.
There is going to be a cost for providing this service. And it may be possible to generate the funds to pay for the service like this. Or if you made sure to include some proof of stake coins in the gateway inclusions and had enough of them banked to get fees for them (if that is possible).
Maybe that is crazy.
I think the AE is awesome and what you are doing with it is awesome. Game changing.
For example, if there are 1000 people with money in the holding account it would be very unlikely that they would all want to withdraw at the same time. Knowing this you could safely lend a portion of the holding account out at interest to cover the cost of the server expense, and maybe bank some of the interest for insurance on the holding account. I don't mean to make a profit, as I understand your reasoning in wanting to provide the service for the worlds benefit, but economics is economics.
There is going to be a cost for providing this service. And it may be possible to generate the funds to pay for the service like this. Or if you made sure to include some proof of stake coins in the gateway inclusions and had enough of them banked to get fees for them (if that is possible).
Maybe that is crazy.
I think the AE is awesome and what you are doing with it is awesome. Game changing.
If I understand correctly, this idea is very bad.
Well it's not a PC, it's server space I'm renting off DigitalOcean to run a VPS. It has 512MB RAM.
Remove "-Xmx1024M". Don't add any Xmx. For VPS it is the best variant.
Btw, managing node can be automated in 2 ways: (1) (2).
I'm still learning linux, I used to do networking and website hosting in the early 2000s but fell out. This whole crypto thing has reignited my passion for computer tech, so now I'm working on catching up to be a techie once again.
I need to do it the hard way to learn
It's not hard to start Nxt on VPS.
Code:
sudo apt-get update && sudo apt-get install openjdk-7-jre unzip
wget http://download.nxtcrypto.org/nxt-client-0.8.3.zip
unzip nxt-client-0.8.3.zip
cd nxt
chmod +x run.sh
./run.sh &
The problem is to keep Nxt running after some exception or detecting fork blockchain. Or when you have
26th public node Im managing.
And new update comes in ... http://techcrunch.com/2014/02/15/kickstarter-coins-2/?ncid=reddit_social_share
This article is describing something that sounds a lot like NXTcoins!
One nuance that might have escaped you (it did me at first) is that we dont even need a gateway for NXTcoins. Mined or issued, they immediately infuse NXT AE with additional capital, which is clearly a good thing.
Each NXTcoins gets priced directly in NXT and indirectly to all the cryptos that the gateway supports.
Create a NXTcoins and instantly get a built in decentralized exchange and conversion into dozens of other cryptos. As soon as we get fiat gateways into AE, add conversion to fiat for all the NXTcoins
James
This article is describing something that sounds a lot like NXTcoins!
One nuance that might have escaped you (it did me at first) is that we dont even need a gateway for NXTcoins. Mined or issued, they immediately infuse NXT AE with additional capital, which is clearly a good thing.
Each NXTcoins gets priced directly in NXT and indirectly to all the cryptos that the gateway supports.
Create a NXTcoins and instantly get a built in decentralized exchange and conversion into dozens of other cryptos. As soon as we get fiat gateways into AE, add conversion to fiat for all the NXTcoins
James
This will be big! Moontime...
I have made an internal proposal to the NXTcash team using the latest source code that will allow us to make a release that can be considered for mainnet use. Not sure how long it will take as I will need to start and finish Nodecoin 2.0 to fully implement the proposed NXTcash solution, not to mention a fair amount of work in the client code.
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Sounds like you're talking about using another chain for the zero-knowledge proofs and putting the hash (pointer) of the ZK block in the Nxt blockchain via AM, effectively using the PoS of Nxt to secure the second chain, no?
James
Cool. Parallel chains, here we come.
Finally
Well it's not a PC, it's server space I'm renting off DigitalOcean to run a VPS. It has 512MB RAM.
Remove "-Xmx1024M". Don't add any Xmx. For VPS it is the best variant.
Btw, managing node can be automated in 2 ways: (1) (2).
I'm still learning linux, I used to do networking and website hosting in the early 2000s but fell out. This whole crypto thing has reignited my passion for computer tech, so now I'm working on catching up to be a techie once again.
I need to do it the hard way to learn
I have made an internal proposal to the NXTcash team using the latest source code that will allow us to make a release that can be considered for mainnet use. Not sure how long it will take as I will need to start and finish Nodecoin 2.0 to fully implement the proposed NXTcash solution, not to mention a fair amount of work in the client code.
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Sounds like you're talking about using another chain for the zero-knowledge proofs and putting the hash (pointer) of the ZK block in the Nxt blockchain via AM, effectively using the PoS of Nxt to secure the second chain, no?
James
Cool. Parallel chains, here we come.
I have made an internal proposal to the NXTcash team using the latest source code that will allow us to make a release that can be considered for mainnet use. Not sure how long it will take as I will need to start and finish Nodecoin 2.0 to fully implement the proposed NXTcash solution, not to mention a fair amount of work in the client code.
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Sounds like you're talking about using another chain for the zero-knowledge proofs and putting the hash (pointer) of the ZK block in the Nxt blockchain via AM, effectively using the PoS of Nxt to secure the second chain, no?
James
I have made an internal proposal to the NXTcash team using the latest source code that will allow us to make a release that can be considered for mainnet use. Not sure how long it will take as I will need to start and finish Nodecoin 2.0 to fully implement the proposed NXTcash solution, not to mention a fair amount of work in the client code.
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
...
Sounds like you're talking about using another chain for the zero-knowledge proofs and putting the hash (pointer) of the ZK block in the Nxt blockchain via AM, effectively using the PoS of Nxt to secure the second chain, no?
I have made an internal proposal to the NXTcash team using the latest source code that will allow us to make a release that can be considered for mainnet use. Not sure how long it will take as I will need to start and finish Nodecoin 2.0 to fully implement the proposed NXTcash solution, not to mention a fair amount of work in the client code.
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
Show your support for NXTcash, donate to completion bounty fund 13313092584524529006
The way I see this working is that from the client you can directly mint new NXTcash, in increments of 100NXT. This will create private files that are encrypted and stored on your computer (and USB backup). Now the files on your USB are just like cash. You can then go to any other computer and launch the NXTcash spending app. You tell it what NXT acct (different one) to fund with the private files on USB.
At this point, we can go in two possible ways, one way is to have the new NXT acct funded with NXT, or it could be NXTcash asset. We are assessing the tradeoffs between the two approaches, but either way, funds have gone from the initial acct to the new account, without any identifiable information being leaked!
What you do with your NXTcash is your business. Anything you do from the alter-ego acct is all publicly viewable, but the key is that nobody can identify who is controlling that new account.
James
Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.
Show your support for NXTcash, donate to completion bounty fund 13313092584524529006
The way I see this working is that from the client you can directly mint new NXTcash, in increments of 100NXT. This will create private files that are encrypted and stored on your computer (and USB backup). Now the files on your USB are just like cash. You can then go to any other computer and launch the NXTcash spending app. You tell it what NXT acct (different one) to fund with the private files on USB.
At this point, we can go in two possible ways, one way is to have the new NXT acct funded with NXT, or it could be NXTcash asset. We are assessing the tradeoffs between the two approaches, but either way, funds have gone from the initial acct to the new account, without any identifiable information being leaked!
What you do with your NXTcash is your business. Anything you do from the alter-ego acct is all publicly viewable, but the key is that nobody can identify who is controlling that new account.
James
So I've been having trouble setting up a node under Debian.
This is the error I get after 0.8.3 starts:
./run.sh: line 1: 3004 Killed java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
Help is appreciated.
This is the error I get after 0.8.3 starts:
./run.sh: line 1: 3004 Killed java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
Help is appreciated.
did you use apt-get to install java? give us output from "uname -a" and "which java" and "java -version"
uname: Linux 5inko.2 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
which java: /usr/bin/java
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
thanks in advanced, need to learn me some more linux.
I'm also using OpenJDK 1.7.0 but on Ubuntu. How much RAM does your machine have?
Well it's not a PC, it's server space I'm renting off DigitalOcean to run a VPS. It has 512MB RAM.
So I've been having trouble setting up a node under Debian.
This is the error I get after 0.8.3 starts:
./run.sh: line 1: 3004 Killed java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
Help is appreciated.
This is the error I get after 0.8.3 starts:
./run.sh: line 1: 3004 Killed java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
Help is appreciated.
did you use apt-get to install java? give us output from "uname -a" and "which java" and "java -version"
uname: Linux 5inko.2 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
which java: /usr/bin/java
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
thanks in advanced, need to learn me some more linux.
I'm also using OpenJDK 1.7.0 but on Ubuntu. How much RAM does your machine have?
So I've been having trouble setting up a node under Debian.
This is the error I get after 0.8.3 starts:
./run.sh: line 1: 3004 Killed java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
Help is appreciated.
This is the error I get after 0.8.3 starts:
./run.sh: line 1: 3004 Killed java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
Help is appreciated.
did you use apt-get to install java? give us output from "uname -a" and "which java" and "java -version"
uname: Linux 5inko.2 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
which java: /usr/bin/java
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
thanks in advanced, need to learn me some more linux.
Suggested NIP (Nxt Improvement Proposal)
Adding "meta information" to Arbitrary Messages.
...
1) Encode them as URIs (making it simple for web apps to handle different kinds of things).
or
2) Use the first x bits of the AM to indicate the type.
Is there a way to do both? Since URI will be a lot longer than 4 bytes, we could reserve a four byte code that web apps could read, which would mean the URI immediately follows. It is is not the code for URI follows, then the web apps should ignore it. Apps that need to use all the 1000 bytes would be able to filter the AM's that just have their special code.Adding "meta information" to Arbitrary Messages.
...
1) Encode them as URIs (making it simple for web apps to handle different kinds of things).
or
2) Use the first x bits of the AM to indicate the type.
Yes. The suggestion of 7-bit ASCII with a variable length allows the type-tag to be dual-purposed as a URI as long as the string starts with a known URI scheme.
Suggested NIP (Nxt Improvement Proposal)
Adding "meta information" to Arbitrary Messages.
As AMs are going to become a key communication tool for various other parts of the Nxt system (including NIPs themselves) I suggest that we decide on one of the two ways of providing minimal "meta" information for AMs.
This could be done in the following 2 ways:
1) Encode them as URIs (making it simple for web apps to handle different kinds of things).
or
2) Use the first x bits of the AM to indicate the type.
The advantage of 1 is the simplicity for web apps (i.e. no coding necessary) and the advantage of 2 is size (we only have 1000 bytes for an AM currently).
Which way we go is up to the community - but whichever way I would like to see then an NIP AM (which might just contain the hash of an NIP document - the document itself could be posted on forums or wherever else).
By having such information your "inbox" could automatically place messages in different folders and could also perhaps sound an "alert" according to the AM type received (e.g. we might expect to also have an "alert" AM a bit like Bitcoin alerts).
Is there a way to do both? Since URI will be a lot longer than 4 bytes, we could reserve a four byte code that web apps could read, which would mean the URI immediately follows. If it is not the code for URI follows, then the web apps should ignore it. Apps that need to use all the 1000 bytes would be able to filter the AM's that just have their special code.Adding "meta information" to Arbitrary Messages.
As AMs are going to become a key communication tool for various other parts of the Nxt system (including NIPs themselves) I suggest that we decide on one of the two ways of providing minimal "meta" information for AMs.
This could be done in the following 2 ways:
1) Encode them as URIs (making it simple for web apps to handle different kinds of things).
or
2) Use the first x bits of the AM to indicate the type.
The advantage of 1 is the simplicity for web apps (i.e. no coding necessary) and the advantage of 2 is size (we only have 1000 bytes for an AM currently).
Which way we go is up to the community - but whichever way I would like to see then an NIP AM (which might just contain the hash of an NIP document - the document itself could be posted on forums or wherever else).
By having such information your "inbox" could automatically place messages in different folders and could also perhaps sound an "alert" according to the AM type received (e.g. we might expect to also have an "alert" AM a bit like Bitcoin alerts).
James
Suggested NIP (Nxt Improvement Proposal)
Adding "meta information" to Arbitrary Messages.
As AMs are going to become a key communication tool for various other parts of the Nxt system (including NIPs themselves) I suggest that we decide on one of the two ways of providing minimal "meta" information for AMs.
This could be done in the following 2 ways:
1) Encode them as URIs (making it simple for web apps to handle different kinds of things).
or
2) Use the first x bits of the AM to indicate the type.
The advantage of 1 is the simplicity for web apps (i.e. no coding necessary) and the advantage of 2 is size (we only have 1000 bytes for an AM currently).
Which way we go is up to the community - but whichever way I would like to see then an NIP AM (which might just contain the hash of an NIP document - the document itself could be posted on forums or wherever else).
By having such information your "inbox" could automatically place messages in different folders and could also perhaps sound an "alert" according to the AM type received (e.g. we might expect to also have an "alert" AM a bit like Bitcoin alerts).
Adding "meta information" to Arbitrary Messages.
As AMs are going to become a key communication tool for various other parts of the Nxt system (including NIPs themselves) I suggest that we decide on one of the two ways of providing minimal "meta" information for AMs.
This could be done in the following 2 ways:
1) Encode them as URIs (making it simple for web apps to handle different kinds of things).
or
2) Use the first x bits of the AM to indicate the type.
The advantage of 1 is the simplicity for web apps (i.e. no coding necessary) and the advantage of 2 is size (we only have 1000 bytes for an AM currently).
Which way we go is up to the community - but whichever way I would like to see then an NIP AM (which might just contain the hash of an NIP document - the document itself could be posted on forums or wherever else).
By having such information your "inbox" could automatically place messages in different folders and could also perhaps sound an "alert" according to the AM type received (e.g. we might expect to also have an "alert" AM a bit like Bitcoin alerts).
Great idea, especially since AM will be used as a reputation system in clients soon.
Once again, someone needs to clarify some things for me. Please correct the following process, it could be total bullshit:
1. James uses AE + AM and three servers to make a gateway for external coins
2. Sending DOGE to the gateway triggers an automated process to send DOGE assets from the Nxt accounts of the servers to the sender's Nxt account
3. Sending DOGE assets back to the gateway triggers the servers to send DOGE coins back to a DOGE address
1. James uses AE + AM and three servers to make a gateway for external coins
2. Sending DOGE to the gateway triggers an automated process to send DOGE assets from the Nxt accounts of the servers to the sender's Nxt account
3. Sending DOGE assets back to the gateway triggers the servers to send DOGE coins back to a DOGE address
cannot log into http://nxtra.org/nxt-client/.
Austin Bitcoin Conference Prep
Heard back from Michael DeMarco over at Freedomain Radio, he asked us to swing by at the Austin Bitcoin Conference. Emails going out, hoping to get quite a few responses in the next few days for our team. First introductions always help get the ball rolling before stepping foot into the chaos.
** Update 1 **
Lamar over at Pheeva would like to meet
http://www.wkyt.com/yourtown/locations/lexington/headlines/Pheeva-has-received-rave-reviews-for-new-product-246776381.html
** Update 2 **
The Bitcoin Wife wants to meet with us, she's already familiar with Nxt!
** Update 3 **
Bitcoin100 - Emailing back and forth now
Heard back from Michael DeMarco over at Freedomain Radio, he asked us to swing by at the Austin Bitcoin Conference. Emails going out, hoping to get quite a few responses in the next few days for our team. First introductions always help get the ball rolling before stepping foot into the chaos.
** Update 1 **
Lamar over at Pheeva would like to meet
http://www.wkyt.com/yourtown/locations/lexington/headlines/Pheeva-has-received-rave-reviews-for-new-product-246776381.html
** Update 2 **
The Bitcoin Wife wants to meet with us, she's already familiar with Nxt!
** Update 3 **
Bitcoin100 - Emailing back and forth now
Jump to: