Tag Archives: nxt

This is a short pictorial I created about who I think might be BCNext, the author of original NXT. This is all speculation, of course, but finding a person who hosted a multibit service on the same IP as the first NXT is a little too suspicious. On closer inspection, we see that he is “…a contract web and blockchain application developer, open source contributor and long distance runner.” In JAVA of course, and he worked for an environmental company! He also says he’s a long term bitcointalk forum member, github shows he has been coding years before Bitcoin was popular. Also, most of his twitter accounts are gone.

Points:

– How many blockchain developers were there in 2014? How many independent, non-forking genuine projects? You could count those on fingers of one hand. Also, all of them were C/C++ developers, only one was a JAVA developer.

– Come-from-Beyond has also been associated with this address, the other project hosted on the IP was “Banana Cash”, which is Russian. Come-from-Beyond has a good command of both English and Russian. He claimed that the ISP assigned that IP to a random other person after he stopped serving the NXT GUI there. The other project must have been either Multibit or Banana Cash, the first one is a JAVA blockchain application and the other one is Russian/English. At least one of those facts is obviously not true.

His LinkedIn profile: http://archive.is/UYzpS
http://www.coindesk.com/cash-strapped-multibit-developers-charge-transaction-fee/

WHOIS entry


% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '88.198.0.0 - 88.198.255.255'

% Abuse contact for '88.198.0.0 - 88.198.255.255' is 'abuse@hetzner.de'

inetnum: 88.198.0.0 - 88.198.255.255
netname: DE-HETZNER-20051227
country: DE
org: ORG-HOA1-RIPE
admin-c: HOAC1-RIPE
tech-c: HOAC1-RIPE
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-by: HOS-GUN
mnt-lower: HOS-GUN
mnt-routes: HOS-GUN
created: 2005-12-27T12:36:33Z
last-modified: 2016-08-25T13:25:28Z
source: RIPE Filtered

organisation: ORG-HOA1-RIPE
org-name: Hetzner Online GmbH
org-type: LIR
address: Industriestrasse 25
address: D-91710
address: Gunzenhausen
address: GERMANY
phone: +49 9831 5050
fax-no: +49 9831 5053
admin-c: TF2013-RIPE
admin-c: MF1400-RIPE
admin-c: GM834-RIPE
admin-c: HOAC1-RIPE
admin-c: MH375-RIPE
admin-c: SK2374-RIPE
admin-c: SK8441-RIPE
abuse-c: HOAC1-RIPE
mnt-ref: RIPE-NCC-HM-MNT
mnt-ref: HOS-GUN
mnt-by: RIPE-NCC-HM-MNT
mnt-by: HOS-GUN
created: 2004-04-17T11:07:58Z
last-modified: 2016-08-25T13:26:09Z
source: RIPE Filtered

role: Hetzner Online GmbH - Contact Role
address: Hetzner Online GmbH
address: Industriestrasse 25
address: D-91710 Gunzenhausen
address: Germany
phone: +49 9831 505-0
fax-no: +49 9831 505-3
abuse-mailbox: abuse@hetzner.de
remarks: *************************************************
remarks: * For spam/abuse/security issues please contact *
remarks: * abuse@hetzner.de, not this address. *
remarks: * The contents of your abuse email will be *
remarks: * forwarded directly on to our client for *
remarks: * handling. *
remarks: *************************************************
remarks:
remarks: *************************************************
remarks: * Any questions on Peering please send to *
remarks: * peering@hetzner.de *
remarks: *************************************************
org: ORG-HOA1-RIPE
admin-c: MH375-RIPE
tech-c: GM834-RIPE
tech-c: SK2374-RIPE
tech-c: TF2013-RIPE
tech-c: MF1400-RIPE
tech-c: SK8441-RIPE
nic-hdl: HOAC1-RIPE
mnt-by: HOS-GUN
created: 2004-08-12T09:40:20Z
last-modified: 2015-08-06T09:39:14Z
source: RIPE Filtered

% Information related to '88.198.0.0/16AS24940'

route: 88.198.0.0/16
descr: HETZNER-RZ-NBG-BLK4
origin: AS24940
org: ORG-HOA1-RIPE
mnt-by: HOS-GUN
created: 2006-01-02T08:59:04Z
last-modified: 2006-01-02T08:59:04Z
source: RIPE

organisation: ORG-HOA1-RIPE
org-name: Hetzner Online GmbH
org-type: LIR
address: Industriestrasse 25
address: D-91710
address: Gunzenhausen
address: GERMANY
phone: +49 9831 5050
fax-no: +49 9831 5053
admin-c: TF2013-RIPE
admin-c: MF1400-RIPE
admin-c: GM834-RIPE
admin-c: HOAC1-RIPE
admin-c: MH375-RIPE
admin-c: SK2374-RIPE
admin-c: SK8441-RIPE
abuse-c: HOAC1-RIPE
mnt-ref: RIPE-NCC-HM-MNT
mnt-ref: HOS-GUN
mnt-by: RIPE-NCC-HM-MNT
mnt-by: HOS-GUN
created: 2004-04-17T11:07:58Z
last-modified: 2016-08-25T13:26:09Z
source: RIPE Filtered

% This query was served by the RIPE Database Query Service version 1.88 (HEREFORD)

He has recently been increasingly active in private repositories, so he might also be working on Ardor (bitbucket supports direct imports).

Larger block size is not an option for any cryptocurrency

Decentralized networks are defined by the lowest common denominator. If you want to push a large amount of data throughout the network, you need to push it everywhere, even to the slowest devices. Also, the mempool synchronization is not, and cannot be, exact. If a peer asks you to synchronize the mempool with them, neither of you know which transactions the other party already has in their pool and which not. In many cases, you end up resynchronizing the entire mempool. Which means that the block size limit now on Bitcoin is not in fact 1 MB, but 1 MB times the amount of users times the amount of mempool block of mempool volume in between blocks. And every time a block sync happens, you need the whole block and mempool to travel across the entire world, to every node. You also need to remember that the mempool synchronization takes away resources shared with block synchronization, so the larger the block limit is, the more unwanted forking happens because the information about new blocks arrives later to many miners – again, exponentially. If anyone with a single-chain solution tells you they can transfer thousands of transactions per minute and satisfy millions of users, they are lying or using cheap tricks.

So the blocksize limit is a technological problem, or more specifically a Bitcoin-related design flaw. Is there a theoretical solution? Yes, since at least 2014, and it’s called sidechains or childchains, and these have been inspired by nothing else than altcoins. Why? Because altcoins in themselves are the scaling solution for Bitcoin, where Bitcoin is only used as the common chain with some market arbitrary value of the altcoin in question. Once you buy an altcoin, you are no longer putting any pressure on the Bitcoin blockchain, until you decide to sell your altcoin and use BTC as a mediator again. Childchains/sidechains are just like that, but only use one network, one dev team, and one common token. It’s like the whole bitcoin/altcoin market virtualized.

Who is working on this technology at the moment? I am not aware if there is any working solution yet, but quite certainly Ardor, or NXT 2.0 development team is releasing their testnet in Q1 2017. It will be spiced up with additional features already present in NXT like the decentralized exchange. Also, Ethereum made some announcements lately and would like to push their solution public early 2017.

Why should you want to use something like this instead of another altcoin? Three reasons – support, price stability and security. Simply, if you use an unknown altcoin because your main coin like BTC has reached it’s technological limit, you are putting yourself at risk of the altcoin holders, who may decide to dump on you. Also, you don’t know how long the chain will be alive, you don’t know if the devs have capabilities of solving issues, etc.

disclaimer: no proofreading done