elective-stereophonic
elective-stereophonic
Show Posts - petko singapore
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.15

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.

Messages - petko

Pages: [1] 2 3 ... 5
1
Quote
It is only necessary that each platform understand how to interpret (and verify the signature of) one extra-platform transaction type - when submitted as an attachment of a native transaction (as described) to unlock a phased transaction. This is the key to guaranteeing that unlocking the funds on one platform can also can unlock the funds on the other (and that the keys are simultaneously accessible to both participants).

This is not enough to guarantee that Bob cannot immediately unlock and claim Alice funds right after she locked the 150 NXT. Bob can submit a valid Ardor transaction (valid bytes, validly signed) on the NXT blockchain, but his account may be already empty on the Ardor blockchain. Which the NXT nodes cannot know because they are not processing the Ardor blockchain, they only check the bytes and signature (right?).

Quote
I am very interested to learn how Migretor implemented their atomic swap protocol. Would you kindly provide a link to this information, or if you have the patience to explain, even if briefly, the protocol?
I think they used the good old atomic swap protocol: https://en.bitcoin.it/wiki/Atomic_swap

Quote
Perhaps it is as simple as a phased transaction on each platform locked by two hashed secrets - only one is known to each. Both transaction's phased block height limits (approximated to time) are staggered so that one expires much sooner than the other and the protocol requires that the trader who has the later limit be the first to broadcast their secret. This will allow a safe margin of time for the trader with the first limit to decide if there is enough time to broadcast both secrets on the opposing platform. Something like this?
Generally yes, but there is only one secret. Something like this:

1. Alice generates a secret and hash-locks her funds for very long time tA > 4 confirmations_periods. Bob can claim the coins during this period if he knows the secret. But only the hash of the secret is known here.
2. Bob waits for 1 confirmations_period and locks his funds on his blockchain with the same hash which Alice used, for a period of tB < tA - 2 confirmations_periods
3. Alice waits for 1 confirmations_periods and claims Bob's funds. This shows the secret. Notice that she can wait almost until Bob's lock period ends. So Bob's period must end before Alice's period, or else she can get back her coins and also claim Bob's coins.
4. Bob now knows the secret and has at least 1 confirmation_time to claim Alice coins.

2
Quote
Each platform must understand how to verify ordinary signed sendMoney transactionBytes of each other. So NXT should understand ARDOR's and vice versa

This is not applicable. We don't want the Ardor nodes to be forced to process the NXT chain and vice versa.

But why do you avoid the standard atomic swap protocol, based on hashed secret? It doesn't require the trading blockchains to understand each-other. And we already have the tools for that - phasing by hashed secret. Actually the Migrator project already worked on atomic swaps between Ardor child chains, NXT, BTC, ETH, etc.

3
Ardor General Discussion / Re: Burn Account
« on: March 19, 2019, 06:44:14 am »
What if a e.g. 20 random users can provide a random word which then will randomly be put together to a passphrase/new address and prove of this will be stored on the blockchain.

no one would know who participated, which words were sent in and in which sequence.

would that work?

This is getting much more controversial. Will be harder to persuade everyone that the 20 users are chosen at random

4
Ardor General Discussion / Re: Burn Account
« on: March 19, 2019, 06:41:59 am »
I would go this way:
1. Let's say, starting from block 644000, take the last number (or which ever) from the next 5 blocks ID's. Last number of 644001 is A, 644002 is B,....,644005 is E.
2. By combining these five numbers, you get block height ABCDE.
3. Get that block hash.
4. combine previous block hash, ABCDE block hash and next block hash. Sha256 that set and get some public key.
5. Generate account ID from this generated public key.
Is that makes sense?

It makes sense, actually this looks like @riker 's approach. We can go with this ceremony too. My ceremony looks more simple to me, but maybe it will cause controversy.

Besides being slightly more complicated, another problem with your approach is that not all 256 bit numbers are canonical public keys. So there is some probability that we end up with a non-canonical public key and that we have to repeat the ceremony. Since I don't understand cryptography, I'm not sure what exactly is the probability, but it is significant - maybe 50%.

5
Ardor General Discussion / Re: Burn Account
« on: March 18, 2019, 08:32:06 pm »
Why not chose an address like ARDOR-0000-0000-0000-00000?
As far as I understood 0 or O are not allowed, buy maybe they can be used as a destination address for an exceptional burn token address?
First, the ARDOR-??? addresses use Reed-Solomon error correction, so ARDOR-0000-0000-0000-00000 particularly is invalid.

The account with numeric id 0 (ARDOR-2222-2222-2222-22222 is RS format) is used to designate a "missing account" situation in binary data, so we cannot use it.

If we use any other magic 64-bit value, it could be much more easily brute-forced. Maybe the person who proposes the value already brute-forced it?

6
Ardor General Discussion / Burn Account
« on: March 18, 2019, 07:51:09 pm »
In Nxt, burning tokens was done by sending them to the Genesis account. The Genesis account was removed in Ardor and now we are facing the problem of how to provably burn tokens. For this we (obviously) need to send the tokens to an account for which it is guaranteed that no one in the World will ever be able to unlock it. So how to get such account?

Since public keys are 256-bit numbers, the simplest approach is to choose a public key in such way that it is obvious for everyone that the person who chose the number, couldn't possibly know the matching private key.

So now I choose the number 618debcd12fe01a90559b1501f27969ea5ac7675bcf7454bf015b685059e3f49, which is the SHA256 hash of the word "Burn Account". You can check that by running

Code: [Select]
echo Burn Account|sha256sum
I obviously chose to hash (with the algorithm which is most commonly used in the project) a combination of two words, which makes sense in the context of burn account. Does anyone think that I could possibly know the private key matching this public key? I.e. does anyone think that I could have possibly iterated so many private keys that I found a public key which makes sense in the current context?

This is kind of social experiment which aims to clarify how much controversy will this approach gather. I.e. if I cannot persuade everyone that it is not possible for me to know the private key, we better not use this approach in the first place.

7
Nxt Helpdesk / Re: NXT node issues
« on: June 09, 2018, 12:16:37 pm »
Whose node API do you pull the peers information from? Apparently that node is not connected to 2 of your nodes, which is normal (we don't want all nodes to be connected to all other nodes). You can force a node to connect to some other node(s) only if that node is under your control. Use the addPeer API for that (or the "Add Peer" button in Peers screen).

Currently requests to your nodes time out from here.

8
Ardor General Discussion / Re: [ARDOR] all bundlers down situation
« on: January 12, 2018, 10:53:12 am »
You cannot have custom code for a child chain which is not executed by the main chain forgers

How then Jelurida would prefer that one would write decentralized gateway to other blockchain?

Let's say one would like to connect EOS (https://eos.io/) with Ardor-world by creating custom child-chain AEOS. How to achieve that?

If you mean a gateway similar to the AEUR chain, yes it is possible, but it will not be decentralized. The AEUR pegged child chain is centralized - a company will hold a fiat EUR reserve equal to the AEUR coins in circulation. Similarly to Tether.

There is an idea about atomic swaps between blockchains which implements a decentralized exchange between the blockchain tokens. I.e. the atomic swaps connect two blockchains in a decentralized way. Up to my knowledge there is nothing working so far. I think Komodo are most advanced with this idea.

But atomic swaps don't have much to do with child chains - a custom child chain is not necessary for that and does not help at all. What is necessary is that each of the blockchains supports a way to transfer funds conditionally if a secret is revealed, or return the funds to the original owner if the secret is not revealed in a previously negotiated period. In Ardor and NXT this can be achieved with a phased transaction with by-hash voting.

9
Ardor General Discussion / Re: [ARDOR] atomic swap of two coins
« on: January 12, 2018, 10:23:21 am »
So can I trade (on internal exchange) an AEUR for an asset issued on IGNIS? (child1_coin<->child2_asset)

Yes, assets are global - you can trade them for each child chain token

10
Ardor General Discussion / Re: [ARDOR] all bundlers down situation
« on: January 11, 2018, 05:36:30 pm »
I imagine that in near future there will be dozens of child chains. Many with custom codebases as they will perform very custom businesses. The natural, and healthy, way would be to let them live their own life, run their own nodes - this is how I see this. I would not believe in situation that on each small update to my ABC child-chain I will need to ask Jelurida to include that software into Ardor's software, prepare release and ask all node maintainers to perform an update...

Ardor child chains are not about flexibility, but about scalability. You cannot have custom code for a child chain which is not executed by the main chain forgers

11
Ardor General Discussion / Re: [ARDOR] atomic swap of two coins
« on: January 11, 2018, 05:22:34 pm »
Specifically with ARDR you cannot swap because phased transactions are not supported on the main chain. You can do atomic swaps between child chain tokens, but it doesn't make much sense with the coin exchange available.

12
Ardor General Discussion / Re: [ARDOR] transactions fee
« on: January 11, 2018, 04:51:22 pm »
Here are the minimum fees currently enforced:

https://www.jelurida.com/ardor-fees

For a single transaction, more than one type of fee may be payed - e.g. if the transaction is phased, contains a message and creates a new account, it must pay all 4 types of fees. So returning the fees by transaction type may not be enough for the UI to correctly calculate the fee

13
Ardor General Discussion / Re: [ARDOR] child chain creation
« on: January 11, 2018, 04:42:38 pm »
Hi kermitas,

Sorry for the delayed answer.

The goal of parent-child chain design is that child chains don't take care of themselves (otherwise they would have been just alt-coins). This way processors of the blockchain (the client software) is not required to process all child chain transaction in order to find out whether the parent chain forgers indeed owned the stake necessary to forge the respective block. So child chain transactions can be pruned.

Pruning of child chain transactions is not implemented yet, so anyone who joins the network must process all history from all child chains. When pruning is enabled, a new node joining the network will only have to process the parent chain until some recent moment, then download the state at that moment and process the transactions until now.

About what happens when a node is kept running:
 * If the node is forging, it must validate all transactions from all chains. Otherwise they risk to forge an invalid block, or on top of invalid chain. Similarly to NXT.
 * A full node which does not forge will also process all transactions because, even with pruning enabled, when the user decides to use it again, the client software will need to either process all transactions from the period it wasn't used, or sync again the state. So, since we cannot know for how long the running client will be left in the background unused, we assume that the user intends to use it soon and continuously process transactions to avoid delays before the client can be used again.
 * It is possible to implement something like the SPV clients known from PoW blockchains. Such client will only process the parent chain and then verify the possessions of the few accounts the user is interested in. But we can work on this only after pruning and state snapshots are implemented.

As a result from the forging requirement, child chains are pretty integrated with each other. There are many object that are global for all chains - e.g. you can register an asset with the IGNIS chain and then pay the fee for its transfer with AEUR. It will not be easy to separate child chains from each other and process only one of the chains. But it also doesn't help with scalability since forgers will still have to process everything.

14
Ardor Software Releases / Re: Ardor v2.0.5e
« on: November 20, 2017, 04:03:44 pm »
1) Yes I mean that,and it's still not visible.My test account is ARDOR-CUKB-BCJ6-KCNK-4KT6U,I use this account issued asset 724795291243904895,I login into ardor.jelurida.com node and still can't see.
2) It's not unconfirmed,and do looks ok from ardor.jelurida.com node and when I switch a browser,so I guess is a cache problem.
3) It's back to "0NaN %" again.

1. Yes, it's a bug. Will be fixed in next version
3. Should be fixed in next version too

15
Yes, your node should automatically blacklist the 7 rogue peers. The code for that is in BlockchainProcessorImpl.java line 655

What is used to decide the "true" chain is the cumulative difficulty of the chain, which is proportional to the amount of forging power used to build that chain.

16
Nxt Helpdesk / Re: Blockchain timestamps
« on: November 14, 2017, 04:37:20 pm »
Transaction timestamps are allowed to drift up to 15 seconds after the block timestamp. To accommodate differences in clocks I guess.

No changes about that recently - it's coming from the initial version by BCNext - see https://bitbucket.org/JeanLucPicard/nxt-public/src/4af2d32ada1b62e0a348809612ee0ed35b49c353/Nxt.java?at=master&fileviewer=file-view-default#Nxt.java-1012 (he checks that transaction is not 15 seconds after curTime, later, in Feb 2014, was added a check that it is not 15 seconds after the block timestamp)

17
Ardor Software Releases / Re: About Asset Control
« on: November 09, 2017, 01:33:44 pm »
After seting Asset Control,seems the issuer can't buy or sell this asset anymore,I keep geting "Non-phased transaction when phasing asset control is enabled" error,only transfer is allowed,I don't think this is correct.

Asset ID:724795291243904895

Asset Control Approval Models
{
  "phasingHolding": "0",
  "phasingQuorum": "1",
  "phasingWhitelist": [
    "16143283123459383641"
  ],
  "phasingMinBalance": "0",
  "phasingMinBalanceModel": 0,
  "phasingVotingModel": 0,
  "description": "Test2"
}

It's a bug (in fact regression). Modals for issuing asset transactions should show a notice to the user that the transaction will be phased, and also let him set the finish height (same like for account control). Should be fixed in next version. Thanks for reporting!

18
Nxt Helpdesk / Re: I can't start Nxt
« on: February 09, 2017, 02:35:30 pm »
Hi, try to run from the nxt directory (in your case ~/nxt must the the current directory)

You can modify run.sh and set the JAVA variable to the path where your java is.

19
Nxt Helpdesk / Re: Roaming Client
« on: September 20, 2016, 08:36:16 am »
As the blockchain is downloading, the NXT desktop programs works through a Roaming Client. But once the download is completed, it doesn't seem to disconnect from the Roaming Client. I have to shut it down, and then restart to accomplish that. Is anyone else seeing this problem?

Hi, before the restart, did you try to refresh the browser?

20
Official Nxt Releases / Re: NRS v1.10.0e
« on: August 04, 2016, 08:39:22 pm »
New NXT user. I bought my first NXT coins a few weeks back. I use Windows 10.

This was my experience and process.

I had been using the NXT wallet and server v1.9.2 and I downloaded the blockchain. I'm not a programmer or super techy but I'm adventurous. I was able to get v1.9.2 working after downloading/installing these programs. Here's what they were:

  • Java Version 8 (build 1.8.0_102-b14) from the java website Java Platform (JDK) 8u101 / 8u102 JRE version
  • Oracle VM VirtualBox
  • Kinematic (Alpha) Docker Toolbox
  • Docker Quickstart Terminal

A couple of days ago v1.9.2 became unstable. :( It wasn't forging, there were flashing red visuals and it was constantly disconnecting. So today I set out to upgrade to v1.10.0e. I first downloaded bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.10.0e.zip

When I ran the .exe file I got an error message saying I needed to install Java. ??? Because I already have Java installed I downloaded bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.10.0e.zip

I ran that .exe and it worked. :) I was back in business with a fully working NXT desktop client. I copied no files over from v.1.9.2. Fortunately, I didn't need to redownload the blockchain and all of my previous settings and bookmarks and info carried over.

Do I need all four of those programs? Can I uninstall any of those?

You only need Java. You can uninstall the 3 other programs.

I don't understand how you fixed the missing Java error. So you first downloaded nxt-client-1.10.0e.zip and you got the error, then you downloaded the same thing again and it worked?

Pages: [1] 2 3 ... 5
elective-stereophonic
elective-stereophonic
assembly
assembly