Bitcoin Forum
December 13, 2024, 04:24:45 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 [1946] 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761621 times)
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 28, 2014, 02:01:17 PM
Last edit: February 28, 2014, 02:19:29 PM by xyzzyx
 #38901

Looks like we will cross 25k NXT accounts today: http://www.mynxt.info/charts/number_of_accounts.php Smiley
{"lastBlock":"11991592437029432970",
"numberOfAliases":63045,
"numberOfBlocks":77224,
"numberOfTransactions":135421,
"version":"0.8.3",
"totalEffectiveBalance":99465935000,
"cumulativeDifficulty":"2406269794605079",
"numberOfAccounts":25420}

Good point Smiley

I wonder where the difference is... probably different way of counting accounts.

One based on account balance of 1 or greater, the other based on existing public key?

The mynxt.info one is done summing up all the unique accounts involved in any transaction since block 0.

Interesting.

I don't really understand Java too well, but from taking a peek at the code it seems "account" is a hashmap and the number of accounts is the number of key-value mappings.

You've made me curious as to what the difference between yours and NRS may be.

Edit: actually, that was true in the old code.  I haven't even looked at the 0.8.x code base which may or may not do things differently now that it has an actual database.  Will have to look at that later.

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
antanst
Sr. Member
****
Offline Offline

Activity: 295
Merit: 260


View Profile
February 28, 2014, 02:10:46 PM
 #38902

ON BEHALF OF CIYAM (China firewall-censorship issues):

a) using a good password create a SHA256 of it
b) publish a hash that is the hash from a hashed “x” times
c) lock your account then after that is confirmed send a tx from your account to another (won’t be able to actually transfer any funds even after confirmed)
d) send a tx that provides the “x-1” hash (i.e. if you hash that you get the hash that was sent in b)
result is that tx from c can now *occur* and also the locking hash has now been changed

Where can I find more technical details about the AC? Is anyone actively working on it?

ziyoubi
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
February 28, 2014, 02:16:07 PM
 #38903

nxt serious coin wish to succeed Wink
lophie
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1001

Unlimited Free Crypto


View Profile
February 28, 2014, 02:31:47 PM
 #38904

awesome ppl, may I have a link to latest source code?

Will take me a while to climb up again, But where is a will, there is a way...
klee
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
February 28, 2014, 02:32:29 PM
 #38905

Pouncer & Anon check ur skype please!
landomata
Legendary
*
Offline Offline

Activity: 2184
Merit: 1000


View Profile WWW
February 28, 2014, 02:35:59 PM
 #38906

ANNOUNCEMENT

Nxt Mobile Applications Company IPO

I am pleased to provide additional information regarding NMAC IPO share placement.  At this moment only 80 million shares are left for sale, 20 million have already been sold.

Due to strong demand we have developed the below allocation formula to be fair to those who expressed strong interest from early January.  As well as to distribute the shares to more investors.

SHARE ALLOCATION FORMULA

1st Tier: 30 million shares (30%)

Maximum that can be purchased: 5,000,000 shares


2nd Tier: 25 million shares (25%)

Maximum that can be purchased: 2,500,000 shares


3rd Tier: 25 million shares (25%)

This allocation will be totally sold on the Nxt Asset Exchange.  The shares will be sold on AE launch day.


The below list are those investors who showed interest in financing NMAC from the beginning of early January.  Those at the top of the list will have first right to purchase shares over those lower on the list.


Pandaisftw - Jan 8
Danniego - Jan 8
Kbk00 - Jan 8
Abctc - Jan 9
Cromaclear - Jan 9
Neer.g - Jan 9
UtopianFuture - Jan 9
Benowl - Jan 9
Hash - Jan 14
Butterclown -  Jan 18
EXtatiC - Jan 21
Shin - Jan 21
Swartzfeger - Jan 22
Ezravdb - Jan 23
Okaynow - Jan 29
LemonAndFries - Feb 8


After business plan published:

Kodtycoon - Feb 25
Smaragda - Feb 25
eB101 - Feb 25
Damelon - Feb 25
KyLins - Feb 25
Rushi - Feb 25
Shenjie - Feb 25
Voldemort628 - Feb 26
Redsn0w - Feb 26
Pt2002 - Feb 27
Stoneone - Feb 27
Bezbezbez - Feb 27
Xcn - Feb 27
Sashsh - Feb 27


This process will run until March 9th, 11:59 PM GMT.  

After this time no one will have precedent over others wanting to buy shares from the 1st or 2nd tier.

PLEASE SEND ME A PM WITH THE AMOUNT OF SHARES  YOU WISH TO PURCHASE.  REQUESTS SHOULD BE WITHIN THE MAXIMUM ALLOWED AS MENTIONED ABOVE.




Re-polished Prospectus/Business Plan  
https://mega.co.nz/#!fEAUlaqD!7_wUKeM6gdtHZdTUrbRRpgg1MS8z_xi38k8IBb5_sJs


Best regards,
Landomata
Secretary
Nxt Mobile Applications Company

mthcl
Sr. Member
****
Offline Offline

Activity: 376
Merit: 300


View Profile
February 28, 2014, 02:36:44 PM
 #38907

Just an update on my recent calculations.

I'm assuming that the algorithm currently used may be roughly approximated by the following model. Let gi be the balance of ith account expressed in billions of NXT (so the sum of all balances equals 1). To decide who will generate the next block, take i.i.d. Uniform[0,1] random variables U1,...,Un (n is the total number of accounts; I'm assuming also that they are all forging), and calculate Wi=gi/Ui. The account for which W. is maximized, will forge, and the corresponding weight is called the weight of the block.

As noted before, this approach slightly favors bigger accounts; in order to make the forging power exactly (up to computational errors) proportional to the balance, one must use Wi=gi/|ln Ui| instead. CfB told me that BCNext preferred not to use logs in order to discourage splitting of big accounts (what for - anybody knows?). Anyhow, if all gi s are small (compared to total amount), then the two approaches are almost indistinguishable, and it's easy to justify it mathematically (will do it in the paper).
In the case of concurrent blockchains, wins the one for which the sum of inverse weights is minimal. (Currently wins the longest one, but these two approaches are, in fact, equivalent.)

Now, we consider the following situation: one big bad guy has b billions-of-NXT, and the others are poor, honest, and many. The bad guy (with his minions) "accidentally" disconnects from the network, and secretly forges a branch of length m. Let us consider the (future) situation with one-block-per-minute, and estimate the probability that this "bad" branch wins over the "good" one.

In the "ideal" situation (when the forging power is exactly proportional to the balance, the above approach with logarithms), the probability of this event will be of order
(4b(1-b))m   for b<0.5.
Observe that 4b(1-b)<1 for b<0.5, so the probability decreases rather fast.

On the other hand, with the current setup (when one divides by uniform r.v. instead of dividing by log of it), this probability only tends to 0 for b<1/3 (I'll write the formula in the paper, since it's much more complicated). The reason for this is easy to explain: the inverse weight produced by good guys has Exponential(1-b) distribution, and so its expectation is 1/(1-b). Now, the inverse weight produced by the bad guy has Uniform[0,1/b] distribution, with expectation 1/(2b). Solving 1/(1-b)<1/(2b), we arrive to b<1/3.

Now, I'm not sure if there is a mathematical solution about how to fence off an attack of someone with b>1/3 (or b>0.5 in the other setting)...

In the next couple of weeks I'll go to a conference in Ulm and then receive an important visitor, so, most probably, I won't be able to read this thread in full (though, of course, I'll check PMs and read Damelon's summaries). Sure, I promise to type all these calculations in an organized way (style of modern math paper; will try to speed it up). Please, discuss it at https://forums.nxtcrypto.org/, this topic: https://forums.nxtcrypto.org/viewtopic.php?f=17&t=836
User500
Newbie
*
Offline Offline

Activity: 41
Merit: 0


View Profile
February 28, 2014, 02:40:25 PM
 #38908

What is the advantage of limiting the block size to 255 txs?

Am pretty sure the current limit is actually 250 - but that would not be expected to stay down the track (think of it as being currently "in beta").


Ok, so what limits the block size? Is it the computational power of the forging node?

Why don't set the block size to 120.000 txs so we would have 2000 txs/s with a block time of 60sec.
Anon136
Legendary
*
Offline Offline

Activity: 1722
Merit: 1217



View Profile
February 28, 2014, 02:41:15 PM
 #38909

Pouncer & Anon check ur skype please!

says you are offline

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 28, 2014, 02:50:08 PM
 #38910

People this thread is giving me headhache and we are losing a ton of time reading thing and searching the subject that we are interesting, we need really to move to a forum with nice functionnality.

Also, I lost my password to my user account at https://forums.nxtcrypto.org/ and it seem that there is no way to recover it. I have contact twice the official forum e-mail. I did not get any answer for since 11 feb. It look like the https://forums.nxtcrypto.org/ is dead.

Any help?

btc24@bitcointalk is adminius@forums.nxtcrypto, the admin of those forums.  I dont think hes been online in a month.  I have been trying to give him some bounty from neer.g but he seems to have completely disappeared.  that being said, i know hes been asked by tons of people to allow password resets by email, but so far hasnt budged.

that being said, if the community as a whole wants to get yet another forums site up and running and volunteer admined then I suppose that can be done.  And if indeed btc24 has been hit by a bus then I guess eventually the forums will break or miss payment and get shut downl i could then change DNS to the new forums if necessary.

or whatever the community as a whole agrees on I will change DNS
LiQio
Legendary
*
Offline Offline

Activity: 1181
Merit: 1002



View Profile
February 28, 2014, 02:59:18 PM
 #38911

awesome ppl, may I have a link to latest source code?

https://github.com/stevedoe/nxt-client
(source of link: https://nextcoin.org/index.php/topic,3733.msg35165.html#msg35165 )
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 28, 2014, 03:24:40 PM
 #38912

Just a reminder: BCNext don't want NXT to be a currency. Coins on top of Nxt should be. Does this change anything?

Does this change anything regarding instant confirmation discussion?

No.

I thought the whole point of using instant transactions was for using NXT as currency.
 Huh
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
February 28, 2014, 03:26:08 PM
 #38913

"If we have coins on top of Nxt, does this change anything in our discussion" I just wanted to remind everyone of BCNext's idea.

So now we can go ahead an talk about instant transactions for NXT.
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 28, 2014, 03:28:23 PM
 #38914

I'm trying to simulate TF using Ian's program if we limit all accounts to a 1% forge balance.  Using 100 accounts holding 1% of the currency over a ten year period, I'm getting a combined best streak of ~23.  This is combining the first 50 accounts.  (These are the accounts assumed to be under the same control.)

Code:
// Copyright (c) 2014 CIYAM Developers
//
// Distributed under the MIT/X11 software license, please refer to the file license.txt
// in the root project directory or http://www.opensource.org/licenses/mit-license.php.

#include <ctime>
#include <cmath>
#include <cstdlib>

#include <string>
#include <vector>
#include <sstream>
#include <iostream>

//#define NUM_DAYS 1
#define NUM_YEARS 10

#define PENALISE_HIGHER_STAKE
//#define PREVENT_IMMEDIATE_REPEAT

//#define SHOW_WINNERS
//#define SHOW_WINNERS_WEIGHT

using namespace std;

const int c_combined_proportion = 2;

#ifndef NUM_YEARS
const size_t c_num_blocks = 1440 * NUM_DAYS;
#else
const size_t c_num_blocks = 1440 * 365 * NUM_YEARS;
#endif

int main( )
{
#ifdef SHOW_WINNERS
   string winners;
#endif
   vector< int > wins;
   vector< int > streaks;
   vector< int > balances;
   vector< int > penalised;
   vector< int > penalising;
   vector< int > best_streak;

   vector< int > combined;
   vector< long > weights;

   long total_balance = 0;

   int combined_streak = 0;
   int best_combined_streak = 0;

   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );
   balances.push_back( 1 );

   srand( ( unsigned int )time( 0 ) );

   for( size_t i = 0; i < balances.size( ); i++ )
   {
      total_balance += balances[ i ];

      wins.push_back( 0 );
      weights.push_back( 0 );
      streaks.push_back( 0 );
      combined.push_back( 0 );
      penalised.push_back( 0 );
      penalising.push_back( 0 );
      best_streak.push_back( 0 );
   }

   size_t last_winner = 0;
   for( size_t blocks = 0; blocks < c_num_blocks; blocks++ )
   {
      long total_weight = 0;
      for( size_t i = 0; i < weights.size( ); i++ )
      {
         if( penalising[ i ] )
         {
            --penalising[ i ];
            weights[ i ] = 0;
         }
         else
         {
            int divisor = rand( ) % 10;

            if( divisor == 0 )
               ++divisor;

            weights[ i ] = ( rand( ) % 10000 ) * ( balances[ i ] / divisor );

            if( weights[ i ] == 0 )
               ++weights[ i ];

            total_weight += weights[ i ];
         }
      }

      if( total_weight == 0 )
         ++total_weight;

      size_t winner = 0;
      size_t runner_up = 0;
      long best_target = 0;
      long second_best_target = 0;

      for( size_t i = 0; i < balances.size( ); i++ )
      {
         long adjusted_weight = weights[ i ] * 1000 / total_weight;

         if( adjusted_weight > best_target )
         {
            winner = i;
            best_target = adjusted_weight;
         }
         else if( adjusted_weight > second_best_target )
         {
            runner_up = i;
            second_best_target = adjusted_weight;
         }
      }

#ifdef PENALISE_HIGHER_STAKE
      if( best_target == 350 ) // an above median value
      {
         ++penalised[ winner ];
         penalising[ winner ] = 1440;
      }
#endif

#ifdef PREVENT_IMMEDIATE_REPEAT
      if( winner == last_winner )
         winner = runner_up;
#endif

#ifdef SHOW_WINNERS
      winners += ( char )( 'a' + winner );
#  ifdef SHOW_WINNERS_WEIGHT
      ostringstream osstr;
      osstr << best_target;
      winners += "(" + osstr.str( ) + ")";
#  endif
#endif
      ++wins[ winner ];

      if( winner < balances.size( ) / c_combined_proportion )
      {
         ++combined_streak;
         if( combined_streak > best_combined_streak )
            best_combined_streak = combined_streak;
      }
      else
         combined_streak = 0;

      if( winner == last_winner )
      {
         ++streaks[ winner ];
         if( streaks[ winner ] > best_streak[ winner ] )
            best_streak[ winner ] = streaks[ winner ];
      }
      else
         streaks[ winner ] = 0;

      last_winner = winner;
   }

   cout << "blocks = " << c_num_blocks << endl;

   for( size_t i = 0; i < balances.size( ); i++ )
      cout << ( char )( 'a' + i ) << " = " << balances[ i ] << endl;

#ifdef SHOW_WINNERS
   cout << winners << endl;
#endif
   for( size_t i = 0; i < wins.size( ); i++ )
      cout << "wins( " << ( char )( 'a' + i ) << " ) = " << wins[ i ] << endl;

#ifdef PENALISE_HIGHER_STAKE
   for( size_t i = 0; i < penalised.size( ); i++ )
      cout << "penalised( " << ( char )( 'a' + i ) << " ) = " << penalised[ i ] << endl;
#endif

   for( size_t i = 0; i < best_streak.size( ); i++ )
      cout << "best_streak( " << ( char )( 'a' + i ) << " ) = " << ( best_streak[ i ] + 1 ) << endl;

   cout << "best_combined_streak = " << best_combined_streak << endl;
   cout << "(combined the first " << ( balances.size( ) / c_combined_proportion ) << " accounts)" << endl;
   cout << balances.size() << endl;
}

very cool.  I cant do this type of stuff - too busy with other things.  I have a question of this scenario though; is it adding even more risk by prohibiting full balances from forging?  If we prohibit lots of NXT from forging, then does the possibility of someone obtaining 90% of forging power (though forcing to use multiple accounts to do so) actually increase?
rickyjames
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
February 28, 2014, 03:30:11 PM
 #38915

NXT FUNDING COMMITTEE VOTE STARTS IN UNDER 9 HOURS AT 12:01 AM MARCH 1 (UTC)

ALL SLATES COMPETITIVE - THIS VOTE WILL DETERMINE WINNERS AND LOSERS FOR ALL COMMITTEES

CANDIDACY DECLARATION CLOSES ONE HOUR BEFORE VOTING STARTS. 
DECLARE YOUR CANDIDACY BY 11:01 PM FEB 28 (UTC)


If you are an established NXTer and want to be on a NXT funding committee, go here:
(previous nominees get automatic inclusion on slate; all others vetted by rickyjames, whose decision is final):

https://bitcointalk.org/index.php?topic=479167.msg5280476#msg5280476

Background:

https://bitcointalk.org/index.php?topic=345619.msg5280786#msg5280786

Good luck to these nominees who have declared themselves candidates:

NXTmarketingfund: allwelder, Damelon,  Mario123, Asian Prepper, joefox, brooklynbct, CoinTropolis_NiftyNikel, Uniqueorn, salsacz, CoinTropolis_JustaBitTime
NXTtechdevfund: EmoneyRu, Anon136, l8orre, abuelau, antanst, BaiMangal, Jean-Luc, Arckam (aka frmelin)
NXTinfrastructurefund: chanc3r, EvilDave, pandaisftw, ChuckOne, ^[GS]^,ferment
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 28, 2014, 03:33:00 PM
 #38916

The two top 50M accounts!! What is their deal? Why are they not sharing their wealth or participating in the progress of their investment. I mean if we consider that the account No. 3 and No. 4 are DGEX and BTER that means they have almost double amount of coins compared to account No. 5 which has about 29M. That is a huge difference. Honestly I would be really ashamed if I was them and I am sure these two 50M amounts are poke in the eye to any new investor that looks our distribution just like they are poking my eye.

Heck, to start at least get your accounts under 50M so they are in the 40s or divide this 50M into two accounts of 25M, it will definitely look better for newcomers.
I really don't understand this!!

guys, come on... these accounts belonging to exchanges are deposits that people in this very forums have sent to these exchanges, and the exchange is holding them for people just like you and me (assuming we are users of the exchange).  They very well CANNOT just gank the funds and start giving them out to other people.

now some of those very large accounts *are not* exchanges; just single people who are perfectly content to let others do all the heavy lifting.  Some of them are people who are helping out, paying bounties, etc.

nothing really we can do.
lyynx
Sr. Member
****
Offline Offline

Activity: 380
Merit: 275



View Profile
February 28, 2014, 03:36:58 PM
 #38917

We are in need of a web developer to work on the front end of our Nxt/BTC Exchange

Must have Java Experience, JQuery, Ajax and PHP or Ruby

We are looking to implement a responsive front end to interact with our Java based back end. All variables are set and can be called from one file, so not a lot of creating and more redesign/implementing involved. Currently, we have basic functions implemented, but are now looking to make it look professional and extend all functionality in a responsive framework.

If interested, please PM me, including links to or applications sites worked on. Payment will be in Nxt. Established community members in good standing preferred.

opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 28, 2014, 03:44:06 PM
 #38918

ON BEHALF OF CIYAM (China firewall-censorship issues):

a) using a good password create a SHA256 of it
b) publish a hash that is the hash from a hashed “x” times
c) lock your account then after that is confirmed send a tx from your account to another (won’t be able to actually transfer any funds even after confirmed)
d) send a tx that provides the “x-1” hash (i.e. if you hash that you get the hash that was sent in b)
result is that tx from c can now *occur* and also the locking hash has now been changed

lol wut
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
February 28, 2014, 03:52:56 PM
 #38919

Hey I have a question with transaction malleability.  From the NXT Wiki:
Quote
Transaction malleability is an issue with Nxt, as it is with all cryptocurrencies. Do not rely on a transaction ID alone to verify transactions!
...  So if an exchange should not rely on just looking for a transactionID, what is the proper method?  Do they have to attempt to track sendingAccountID, receivingAccountId, and amount?
- there was the CfB's answer:
It's a problem only for exchanges that rely solely on transaction id. It doesn't need to be fixed. An exchange is supposed to pay attention to timestamp and other parameters of a transaction.
what parameters ,except timestamp?
Amount or ReferencedTransaction.

Can someone describe to me a practical method to use referencedTransaction for the purposes of exchanges tracking things?  Im going to add more into the exchanges page on Wiki and this will be helpful. But...

Why not be pragmatic here and fix the malleability issue in the NXT protocol?  Would be a nice feather in NXT's cap and would make things much easier for adoption for all the new systems we *want* to come to NXT in the *first* place.  IMO this could be something that allows faster adoption.
redsn0w
Legendary
*
Offline Offline

Activity: 1778
Merit: 1043


#Free market


View Profile
February 28, 2014, 04:16:52 PM
 #38920

Did you want some TestNxt ?
Pages: « 1 ... 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 [1946] 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 ... 2557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!