|
Do you have a trustless escrow?
|
|
|
|
But it was the last Nxt Barbecue and the bacon writes NXT on the grill! Looks good, isn't it ?
ha! doesn't saw this, good one Ludom  lol, really! You didn't see it? Would understand if it was this written in bacon  ^^^ you an do this one this year Ludom  |
|
|
|
So mistyped passphrase  Glad it resolved. |
|
|
|
|
What is your account?
How do you input your password?
Check for a space before and/or after if you copy and paste. Try typing it in by hand otherwise.
What version did you upgrade from?
I suspect you may be inputting your passphrase slightly incorrectly. The tiniest difference (e.g. a space) opens a completely different account. As you are opening an account with zero transactions, you haven't been hacked but are opening up a so far unused account with a different passphrase than you think.
|
|
|
|
|
The problem is, if McDonald's goes alone then network B basically becomes Disney dollars or a loyalty scheme. Network B transactions are only accepted or have value in one place: McDonald's. And they can decide to suspend that at any time without notice or recourse by shutting down network B (granted, they could take them to court in this case but why take the risk when McDonald's could just continue on network A?) Anyone can choose to accept them if they want, but why would they?
It would be like accepting payments from McD's in airmiles or the like, one of your suppliers will need to accept airmiles as payment or you are digging yourself into a hole. Lots of expenses and nothing of value to others that you can use to pay them. Sooner or later, you will have to stop accepting airmiles and go back to the original (e.g. dollars) just to stay in business.
The economic majority holds the balance of power. There is nothing stopping McDonald's forking. But they can't force anyone to use their chain. And, as shown above, there can't be any interaction between the two chains so the fork would need the economic majority for it to stand a chance of surviving long term. i.e. McDonalds forks and takes a fries supplier, a logistics company, a cow farmer, a butcher and 1 billion customers etc. with them and tries to make a sustainable economy.
Another way of thinking of the forking. It would be the same as McDonald's being on the Nxt network but then announcing they are only going to pay suppliers only in a 3 node, $5000 POS coin that is at #970 on CMC (a small economy of limited number of users). Or going from USD to [Island Nation form of currency]. It doesn't make economic sense for them or for their suppliers to follow. Any payments their suppliers receive in the mean time are likely to be worth nothing in the long term as the economy is too small and is most likely to fail.
I would say it is more of an assumption, it follows logic given the economic rules (self interest in preserving the value you have).
|
|
|
|
Their user base is and economy is drastically reduced.
Why, if you can run multiple wallets on different branches? In Wallet A you have 100. McDonalds forks the network with their 5% stake. So now you have Wallet A with 100 and Wallet B with 100. You sell a DVD for 100 on the original A network (95% of economy) and buy a burger for 100 on network B. Your new balances are A = 200, B = 0. McDonald's then tries to buy supplies for 100 they got from B. There is no one who wants to accept their transactions as the economy is so small, there are no fries suppliers running nodes on network B. They are all still doing business on network A. McDonald's can't spend that 100 Nxt on chain A as that 100 is still in wallet A (+100 they got for the DVD). The transaction that moved those coins to McDonald's was on network B. McDonald's tries to convert the 100 to fiat to pay their suppliers. All the exchanges still run network A so they aren't interested in converting their forked coins from network B. McDonald's decides to rejoin chain A rather than go out of business, so all network B's transactions never happened (no nodes running B = no network or history). McDonald's has an economic incentive to stay with the main chain if it wants to stay in business. Users have an economic incentive to stay on the main chain if they want their coins to be useful for transacting with businesses. |
|
|
|
Why would Silkroad and McDonald's choose to be on different chains? There is an incentive for everyone to be on the same chain. If you deliberately fork with 1% of the stake, you are giving people a disincentive to use your chain as you will only be able to transact with 1% of the economy.
Well maybe McD would announce they'll have nothing to do with Silkroad and want a clean, family-friendly fork. And if that happened, users who wanted both services would then have to use two wallets, right? By the same token, maybe they would start their own interwebs as they want a clean, family friendly net? I don't think this is likely scenario. If they did do it deliberately, they would be effectively leaving the network and starting on their own. It would be like "Physical Silkroad" moving it's one department store from America to Tahiti. Their user base is and economy is drastically reduced. Maybe CfB can answer definitively (he wrote Economic Clustering). |
|
|
|
So, a new user starts their node and goes to McDonald's or whoever they want to send transactions to (they both have to be on the same chain for them to be valid). A large enough cluster will reinforce itself for the same reason and forks tend towards 1
So far it is unclear to me how the size of a cluster eliminates forks. What about this scenario: Alice wants to buy an ounce of weed from SilkRoadNXT. So Bob passes him a blockhash and she can sync with the branch where SilkRoadNXT is. Afterwards she gets the munchies, so she wants to buy a burger from McDonalds. She again calls Bob, who passes her a hash from the chain with McDonalds. And from now on, she has two NXT wallets or accounts on her desktop: one for the weed, one for the burgers. (Until eating meat gets criminalized of course) Why would Silkroad and McDonald's choose to be on different chains? There is an incentive for everyone to be on the same chain. If you deliberately fork with 1% of the stake, you are giving people a disincentive to use your chain as you will only be able to transact with 1% of the economy (and the 1% transactions wouldn't be accepted by the 99%). |
|
|
|
|
Are there still plans for pruning? Is it technically possible in BTC?
|
|
|
|
|
Short term consensus in Nxt is still "best chain" or "chain with most work".
Economic Clustering is for long term consensus after a break and you haven't kept up with the blockchain.
So, a new user starts their node and goes to McDonald's or whoever they want to send transactions to (they both have to be on the same chain for them to be valid). A large enough cluster will reinforce itself for the same reason and forks tend towards 1. Once the new user is up to date with the blockchain, economic clustering is no longer required. The user is then competing with McDonald's or whoever to create the "chain with the most work wins" to determine short term consensus.
That is my understanding. CfB has said in the past the BTC and NXT are very similar, if you consider each Nxt a small mining rig.
|
|
|
|
Blockchain Pruning to be included with the next release of Nxt. This will drastically reduce blockchain bloat in future, compared to the blockchain so far Source: https://nxtforum.org/nrs-releases/nrs-v1-5-1e/Release 1.5.1e
This is a development release for testing only. Source code is not provided.
Change log:
This is an experimental release which adds the Prunable Messages feature. It
will be enabled at the same block as the Voting and Phasing features.
This is a required update for all testnet nodes, but is also possible to run
on main net.
New features:
Prunable plain and encrypted messages.
Plain and encrypted messages can now be created as prunable. For a prunable
message, the message data itself is never a part of the transaction bytes.
Instead, only a 32 byte sha256 hash of it is included in the bytes that are
being signed, used to verify the signature, or to generate the full
transaction hash or id. This makes it possible to completely remove the
message data at a later time, keeping only that 32 byte hash, and still be
able to verify the transaction signature and have the transaction hash and
id unaffected by the pruning.
Prunable messages have a predefined lifetime, after which their prunable parts
are deleted from the blockchain. This lifetime is measured starting from the
transaction timestamp of the message. When a node receives a transaction or
a block from a peer, it is only required that the prunable parts of any
prunable message are also included if their expiration time has not yet been
reached. If it has, and a valid message hash is included instead, the block or
transaction will still be accepted.
Currently the minimum lifetime of all prunable data is set to 24 h for testnet,
to allow easier testing of this feature. For main net, it is tentatively set
to two weeks, but this is subject to change before the stable release. Note
that pruning is performed at the same time as derived table trimming, which
by default is every 1000 blocks, so the actual removal of the prunable data
from the database will happen with some delay after their expiration time.
A node can choose to keep prunable messages longer, by setting the
nxt.maxPrunableLifetime property to a larger value. It cannot be set to
prune them earlier. Changing this value only affect transactions received
after the change. Pruning can be disabled completely by setting this property
to -1.
Prunable messages that have not yet been expired, but are past the minimum
lifetime, are only retrievable using the getPrunableMessage(s) APIs, but
are not included as part of their transaction JSON.
If a transaction containing prunable attachments is phased, the prunable
parts are nevertheless saved and available immediately, not at finish height.
If their expiration deadline comes before the phasing finish height, they
will be pruned and not available at finish height.
Fees for prunable message attachments are set at 0.1 NXT per 1024 bytes, with
the first 1024 bytes free (the regular transaction fee depending on its type
still applies). This is again subject to change before the stable release.
The full size of prunable message attachments is limited to 42 kbytes. Note
that the full size is still included for the purpose of calculating the total
block payload, even though only the 32 byte hash is in the transaction bytes.
The size of regular plain and encrypted messages in this release has been
restricted back to 1000 bytes, and will likely be reduced even further, before
the stable release. This will be done in order to encourage users to switch to
prunable instead of regular messages. Fees for regular message attachments
will also be increased substantially.
Creating prunable plain messages of less than 28 bytes is not allowed, as at
such small sizes it is more efficient to store the full message instead of a
32 byte hash of it. There is no lower limit on prunable encrypted messages.
It is not possible for a transaction to have both prunable plain and prunable
encrypted message at the same time. It is also not possible to have both
prunable and regular message of the same type (plain or encrypted). It is
however possible to have a regular plain message and an encrypted prunable
message, or a prunable plain message and a regular encrypted message.
Prunable encrypt-to-self messages are not currently supported as there seems to
be no good use case for them.
Prunable encrypted messages can optionally be compressed before the encryption
(default is to compress). The compression status is stored and does not need to
be specified when decrypting. Regular encrypted messages are still compressed
by default, but this compression can now optionally be disabled. For backwards
compatibility, since their current bytes format does not store the compression
status, this needs to be specified again when decrypting, else an error or
unreadable data will be returned.
New APIs:
GetPrunableMessage - returns the prunable message for a given transaction id,
optionally decrypting it if encrypted and if a secretPhrase is supplied.
GetPrunableMessages - returns all prunable messages for a given account id,
optionally limiting to only those with another account as recipient or sender,
and decrypting them if a secretPhrase is supplied.
Prunable messages that have already been pruned are not returned by the above
APIs.
The UI for those APIs will be implemented in a later release.
TrimDerivedTables - a debug API to trigger a derived tables trim, and prunable
tables pruning.
Changed APIs:
All APIs that create a new transaction now also accept optional
messageIsPrunable or encryptedMessageIsPrunable boolean parameters (default
false). If true, the message or encrypted message attachment, if any, is
created as a prunable message.
To control whether compression is performed before the encryption or not,
the new compressMessageToEncrypt and compressMessageToEncryptToSelf parameters
can be used (default true).
Prunable messages, if not yet pruned, are also returned as part of the
transaction json by the getAccountTransactions API, using the same fields as
the corresponding regular messages, but adding a messageIsPrunable or
encryptedMessageIsPrunable boolean flag.
ReadMessage now also handles prunable message attachments, if any. It takes
an optional uncompressDecryptedMessage and uncompressDecryptedMessageToSelf
(default true) parameters, only used for non-prunable messages (not needed
for prunable ones).
DecryptFrom accepts an optional uncompressDecryptedMessage parameter, and
encryptTo accepts an optional compressMessageToEncrypt parameter, default true.
INCOMPATIBLE changes:
BroadcastTransaction has been modified to optionally accept all parameters that
are needed to create a prunable plain or encrypted message (client side
encryption only). This is required because the data for such messages is never
a part of the transaction bytes themselves, so trying to broadcast a transaction
that has a prunable part by only submitting its bytes to broadcastTransaction
WILL FAIL, unless the corresponding parameters necessary to add the prunable
parts are also supplied. Note that they need to exactly match the original
parameters with which the transaction bytes have been created and signed.
For non-prunable messages, broadcastTransaction behaves as before, but users
are encouraged to start switching to prunable messages in view of the planned
size restrictions and fee increases.
The EncryptedData java class no longer handles compression internally, this is
left to the caller of the encrypt and decrypt methods to do.
Other changes:
GetPolls now supports an optional includeFinished parameter (default false).
Multiple bugfixes and improvements in the Voting System and Phasing UI.
The limit on transaction deadline of 1440 minutes has been removed. It is now
possible to create a transaction with a deadline of up to 32767 minutes. This
has been done because many use cases of phasing require that the transaction
bytes are prepared much earlier than the actual broadcasting of the transaction
to the blockchain.
This release will perform a database upgrade with a full rescan on first start.
On testnet, it will cause a rollback to block 256935.
|
|
|
|
Would be interested in seeing and updated index |
|
|
|
The problem is not naebe as such, well done guys , but the fact that so many people were led to an obvious naeb . What is a naeb? Scam? Little trolling going on in English atm..  |
|
|
|
Nice one. Anything we can do to help? |
|
|
|
if the title was 'Openbazaar - Official Project Updates' I wouldn't have posted it.
|
|
|
|
If you want to have a look around nxtfreemarket then... https://freemarketlite.cc/...is a pass through web service so you don't have to download anything. It lists the items that are for sale. |
|
|
|
I own a shit ton of NXT
You have already claimed to be a Nxt founder. You have already been asked to prove it, post a token from your whale account. |
|
|
|
|
Show Posts
