Show Posts - bcdev
Please login or register.

Login with username, password and session length
Advanced search  


Latest Stable Nxt Client: Nxt 1.12.2

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - bcdev

Pages: [1] 2
Nxt General Discussion / PPA - the fastest way to install NXT on Ubuntu
« on: September 14, 2016, 09:37:14 am »
Code: [Select]
sudo add-apt-repository -y ppa:nxtcrypto/nxt
sudo apt-get update
sudo apt-get install nxt nxt-bootstrap-blockchain

On a VPS the process took 1m45s from start to end, but that's mainly because it has a fast internet connection.
If you're on a different distribution, here is the blockchain bootstrap.

Nxt Improvement Proposals / Decentralized global alerts
« on: March 28, 2016, 06:18:44 pm »
Alerts for NXT clients that are displayed before and after logging in.

NXT hard forks often. It's a good practice to shout at users that use outdated software that they should upgrade or face eternal damnation.

The decentralized way. Within each block a forger can include a global message and optionally versions that it concerns.
If within last 720 blocks 75% of blocks the message is the same: [ex. "NXT 2.0 fork is coming soon - UPGRADE DAMMIT!" if version < 1.9.0], then the message is displayed.
No secret keys, pure democracy.

Nxt General Discussion / Bootstraping the blockchain
« on: March 23, 2016, 12:50:27 pm »
Right now it takes 1 to few hours to start a blockchain.
1st problem is the time it takes to download whole blockchain.
2nd problem is the time to validate and execute all transactions.

These two problems have quick and easy solution:
Just host an h2 database on DigitalOcean.
Compressed h2 database takes 800MiB. $5/month DO droplet gives 1TB of transfer. Which means that we could bootstrap > 1000 nodes each month for a cost of 0.5c each.

Why? It takes about 10-15 minutes to start an Azure instance. After that it takes > 1 hour to download NXT blockchain. It should be quite easy to decrease that time to 10 minutes, making NXT the fastest blockchain to "Hello world!" on Azure.


I know that bootstrapping of whole database is not trustless and not decentralized. Right now I'm thinking about making Azure integration as painless for a potential business as possible.


An automated process has detected links on this page on the local or global blacklist. If the links are appropriate you may request whitelisting by following these instructions; otherwise consider removing or replacing them with more appropriate links.

Core Development Discussion / NXT upgrade rescans
« on: March 15, 2016, 07:58:37 pm »
Let's say I'm thinking about creating a PPA for NXT.
What would happen is that every time the user does "apt-get upgrade", a new version of NXT would be installed.

During an upgrade NXT would have to be:
1) Stopped
2) Replaced with a new version
3) Started again

However, there is a catch. NXT sometimes does a rescan after a version upgrade.
10 seconds of downtime is perfectly acceptable. An hour is not.

How to tackle this problem?

Nxt General Discussion / Maybe it's time to open the NRS development?
« on: November 06, 2015, 04:14:03 pm »
Maybe it's time to open NRS development? Right now it's completely opaque, it's impossible to audit changes to the core until a release comes out.
AFAIK the point of keeping development process closed was to prevent clones - I'd say it no longer applies, the clones are very small compared to NXT. Clones aren't a threat to Bitcoin, they won't be a threat to NXT.

The recent API compatibility fuckup may not be completely preventable by an open development model, but it'd surely allow someone to spot the disaster before the release.

Jobs board / Anyone needs a programmer?
« on: October 20, 2015, 02:45:11 pm »
I can spare 2-3 hours per day.

I can work on any backend stuff. I suck at frontend, don't expect me to be a competition to Wesley.
Only commercial offers, I have enough free projects on my back.


Commercial experience - 5 years: C, C++, Python, C#. x86&ARM's.
Hobbyist experience - let's say that I installed Mandrake Linux for the first time in 2001. Also, I know a lot about Linux administration, I use it daily both on desktop and on servers.

General / Make sell transactions pay for themselves
« on: October 09, 2015, 05:38:15 pm »
Use case:
Imagine you work for someone. This someone pays you in WhateverToken to an empty account.
Now you have WhateverToken worth 1,000,000NXT stuck because you don't have 1NXT to execute any order.

Make market sells pay for their fees if they're executed immediately and account_balance < fee.

I think that this situation will happen quite commonly with SuperNET. Someone deposits BTC, receives SuperBTC and is stuck because he doesn't have NXT for any operation.

This could be generalized to any asset operation [if you send SuperBTC, you can pay for fees selling to the highest bidder [in the same transaction]], but it's not a good idea IMO.

Currently I weight 103kg. That's 13kg too much. So far I've been bouncing between 100-105 for 1.5 a year, unsuccessfully trying to loose it.
So I have an idea to create an asset bet. Each share's value would be tied to my current weight. My target weight loss would be 0.5kg/week. If I loose more [> 0.5kg], the price of the asset will drop. If I loose less, the price of the asset will increase. That's the overall idea, I'll devise the exact formula later.
The price would be updated every week based on average of a few [4?] weight measurements.
By buying the asset you bet that I'll loose weight slower than 0.5kg/week.
If I get to 90kg in <=13 weeks, the asset would loose 100% value. If in 26 weeks, the asset's price would be the same than on inception. If I get to it in >= 39 weeks, the final asset value would be 200%.
After I get to 90kg [or to 39 weeks], I'll execute the buy wall for the asset and throw away the private key, so that the asset is pegged to NXT at the final value.

No dividends, just pure buy&sell walls [with 0 spread] updated weekly.

Any thoughts?

Alias System / Forgers can steal aliases
« on: September 19, 2015, 02:19:26 am »
If a forger gets a tx that creates an alias he can steal it. Can something be done about it?
The only algorithm I could come up with is two-phase alias creation where one tx creates encrypted alias and a second [block later] reveals the encryption key.

General / Preventing spam by forgers
« on: September 12, 2015, 11:05:43 am »
Right now a forger can create free transactions if he puts them in block that he forged.
Since max tx size is 1kB, that means that a forger can spam 250kB in one block for free.

Make block rewards split between last X forgers.
For example:
60/40 scheme - A forger forges block 1000, 60% of tx reward goes to him, 40% to forger of block 999.
After that forger of block 1001 gives 40% of his reward to the forger of 1000... And so on.
40/30/30 scheme - A forger forges block 1000, 40% of tx reward goes to him, 30% to forger of block 999, 30% to forger of block 998.
After that forger of block 1001 gives 30% of his reward to the forger of 1000 and 30% to 999... And so on.

Overall this scheme would disincentivize transaction spam since even if you forge a block, you'd still pay a fraction of tx price [60/40 - 0.4NXT per tx, 40/30/30 - 0.6NXT per tx].

What do you think of this scheme?

General / How do we know a fork happened?
« on: September 11, 2015, 10:36:23 pm »
Let's say that there is a bug in JVM that makes 32bit machines go nuts.
So the NXT forks. Half of forgers on 32bit chain, half of forgers on 64bit chain.

Is there any mechanism that will flash a red light and yell "FORK HAPPENED, FORK HAPPENED!!!"?

Pub crawl / I hate CloudFlare
« on: April 25, 2015, 05:26:22 pm »

I need to vent my frustration. ;)

I have to enter this ******* captcha on random sites all the time. It doesn't matter that I entered it 1 minute ago on a different site. It doesn't matter that I use Linux and I'm sure I don't have malware. It doesn't matter that I don't share my internet connection with anyone. It doesn't matter that I entered this captchas 100 times already.

Anyone has similar experiences? Anyone has opposite experiences?

Multigateway++ (jl777) / Where can I review the source code?
« on: February 19, 2015, 11:46:43 pm »
Let's say that I'd like to set up Multigateway to review it and understand how it works. Where can I get the source code?
Google didn't bring up any useful links. I'm talking about server, the multisig software, not the client, which is easily available.

Pub crawl / Sleep schedule
« on: October 24, 2014, 03:00:23 am »
Just curious, is anyone here on something other than monophasic?

Pub crawl / 01000111011000010110110101100101001000010010000100100001
« on: October 23, 2014, 11:33:29 am »

Nxt General Discussion / How to decrease 60s block time?
« on: October 16, 2014, 12:12:54 am »
I'm talking about the source code. 10s blocks would be much better for debugging.
5 minutes search didn't work, so it's faster to ask. :D

I'm working on 1.2.8.

Imagine the following situation:
Buyer buys a bunch of [your favorite substance] from the seller on the marketplace.
Afterwards buyer instead of paying, sends seller a hate mail ["You f**** s****!"] and gives the seller a negative comment.

Imagine the following situation:
Worker and employer agree for worker to do particular project for 200NXT. After the works is done, employer pays only 100NXT.

WTF is Proof of communication:
In both above usecases, it'd be very helpful to be able to prove your innocence and the other party's guilt.
If for example [e-bay scenario] you get a negative comment, you can in response you disclose the dishonesty of the other party in an cryptographically undisputable way.

IMO easy. The functionality doesn't require a hard fork. In fact everything could be done in the UI.
Proof of communication needs to have:
1. Transaction id. [64 bits]
2. Key that was used to encrypt the message. [256 bits]

What would it look like?
Code: [Select]
     Message ID                AES Encryption Key

One note: Proof of communication discloses one particular message. So if for example you have a conversation, you'd need to publish as many Poc's as there are messages.

Security / Transaction ID Collision
« on: October 14, 2014, 08:18:14 am »
Transaction ID's are only 64 bit.
So I have a question.
What will happen, when a tx ID collision happens?

-Old and Inactive Projects- / Project NXT Storm
« on: October 13, 2014, 11:29:39 am »
Project NXT Storm - http://nxtstorm.org
Project NXT Storm is a benchmark of NXT network. We're going to test the robustness of the NXT network until it breaks, and see what happens. Basically we're planning a big show with explosions and broken chains! On hundreds of nodes at once. And we hope to find bugs&bottlenecks before they manifest on the mainnet.

The idea is to run the test when NXT 1.3 is released, and then repeat to it every major release [for example when Transparent Forging is implemented] to track the progress.

Design documents
You can review the design documents here:

Test software design
Test description
Not yet available.

Source code
Not yet available.

When will the storm happen?
When NXT 1.3 is released and each major release after that. No ETA is specified yet.

bcdev - nxtstorm@bcdev.net, bcdev at nxtforum.org&bitcointalk.org

I'm looking for developers! There are lots of things to do:
Code - PM contact me
Providing servers - We will need a hundreds of servers to run tests, for a few days. I'll update this page when test software is finished.
Post ideas in test software design
Post ideas in test description

Pages: [1] 2