elective-stereophonic
elective-stereophonic
Current 1.7 changelog  
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.11.15 | Latest Experimental Nxt Client: Nxt 1.12.0e

Pages: 1 2 [3]  All

Author Topic: Current 1.7 changelog  (Read 17090 times)

_mr_e

  • Hero Member
  • *****
  • Karma: +88/-18
  • Offline Offline
  • Posts: 956
    • View Profile
Re: Current 1.7 changelog
« Reply #40 on: November 15, 2015, 03:35:09 pm »

Could we please add a setting that when enabled would automatically show unsigned bytes with the QR code rather then forcing you to click, "do not broadcast" & "do not sign" when the passphrase is not available?
Logged

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: Current 1.7 changelog
« Reply #41 on: November 15, 2015, 03:51:08 pm »

Can we not just wait until MGW devs find a way to switch to prunable or to only use 32 bytes ?
Jean-Luc already offered to delay the new fee block; this can be done without delaying the other new features. He'd need to know how long for.

Increasing the maximum from 160 to 200 bytes might also be possible; Jean-Luc doesn't seem to want to, but I've not seen any rationale for why 160 bytes is the magic number here, rather than 128 or 256. Currently the vote seems to favour 2 NXT basic fee, so 200 bytes would cost 14 NXT. Of course, the next rounds of voting might push the cost up to 21 NXT or 28 NXT. That would provide SuperNet with some incentive to switch to prunable data, so after a while hopefully few transactions would actually be using the extra 40 bytes. Maybe the limit could be dropped again in a year's time, if nobody then needs it.
the minimum size that can be used to correlate a BTC deposit would be the txid + vout, so that is 32 bytes of high entropy + integer, 34 bytes takes care of most cases, but if BTC blocks get bigger and we see more than 65536 vouts in a tx, 35 bytes would be needed.

However, this requires more than just server settings changes and would require a new round of testing. in any case I cannot fit 35 bytes into 32, so it is a moot point as it has been declared that 32 bytes is the limit. Also this assumes only BTC deposits, so all the coins would need to be scanned and what if there is a txid collision between blockchains? It is possible and actually happened in the early btc blockchain, so add another byte for the coin. maybe there will be some other things that are nice to have, like the NXT address of 8 bytes. some coin's txid dont fit into 32 bytes, etc.

As far as how long, this is  a question for vanbreuk and the new MGW dev

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: Current 1.7 changelog
« Reply #42 on: November 15, 2015, 04:00:37 pm »

BTC txfee is .0001 -> ~3 cents and you can put at least 80 bytes in OP_RETURN on the BTC blockchain.

would you pay more to store data in the NXT blockchain vs the BTC blockchain?

economics

price elasticity

these are not hard to understand. expensive things have less volumes than less expensive things.

If the cost to use NXT storage is the most expensive in all of crypto, then it will probably become the least used blockchain storage. Basically unless the effective cost to use NXT is significantly lower than BTC, new use cases wont use NXT. And if it is more expensive, current use cases will be economically forced to migrate

There has been 2 years for NXT ecosystem to develop around the 1NXT per tx and 1000 bytes pricing. If the cost goes up, the usage will go down. If the cost goes down, the usage might go up.

Why not make it cost 1000 NXT per tx and another 100NXT per byte used? that will make 1000x the forging income and everybody will want to forge NXT

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: Current 1.7 changelog
« Reply #43 on: November 15, 2015, 04:26:21 pm »

the minimum size that can be used to correlate a BTC deposit would be the txid + vout, so that is 32 bytes of high entropy + integer, 34 bytes takes care of most cases, but if BTC blocks get bigger and we see more than 65536 vouts in a tx, 35 bytes would be needed.

However, this requires more than just server settings changes and would require a new round of testing. in any case I cannot fit 35 bytes into 32, so it is a moot point as it has been declared that 32 bytes is the limit.
As I understand it, the limit will be 160 bytes. 32 bytes is what you get for the base fee. You can get more space if you pay a higher fee. From the first post in this thread:

Messages and EncryptedMessages (non-prunable):
Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after the first 32 bytes.

If you can fit your stuff into 64 bytes, there's no problem using permanent storage other than having to pay for the second 32 bytes.

Maybe instead of txid you could use the block-height of the transaction plus an index into the block, or some other indexing scheme, to get under 32 bytes. It'll be more work, of course, but might be worth it if you hate prunable data that much, and want to pay the minimum fees. Really the point of the new fee structure is to encourage more efficient use of space in the Nxt blockchain.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #44 on: November 16, 2015, 08:22:57 am »

Can we not just wait until MGW devs find a way to switch to prunable or to only use 32 bytes ?
Jean-Luc already offered to delay the new fee block; this can be done without delaying the other new features. He'd need to know how long for.

Increasing the maximum from 160 to 200 bytes might also be possible; Jean-Luc doesn't seem to want to, but I've not seen any rationale for why 160 bytes is the magic number here, rather than 128 or 256. Currently the vote seems to favour 2 NXT basic fee, so 200 bytes would cost 14 NXT. Of course, the next rounds of voting might push the cost up to 21 NXT or 28 NXT. That would provide SuperNet with some incentive to switch to prunable data, so after a while hopefully few transactions would actually be using the extra 40 bytes. Maybe the limit could be dropped again in a year's time, if nobody then needs it.

160 is a magic number indeed. I was initially thinking of 128 only, then decided to make it 32 for free, plus 128 paid, 160 total.

Changing this limit is not something we can do often, if at all. It must be done now, because 1000 is too high, and the only reason the limit was 1000 before is that we didn't have the prunable feature at that time. But we cannot set the limit to 256 now, and decide to lower it to 128 in the future, this will break client applications. Yes, the current change also breaks them, but it is unavoidable. If we must break them, do it once, and then no more changes in the limit. This is why I would rather delay setting the limit by a few weeks, than set it too high now with an intention to lower it more in the future.

The minimum transaction size now is 176 bytes, for ordinary payment with no attachment. 32 bytes of it is the sender public key with is stored only once per account, so the actual data that such a transaction adds is 144 bytes. Must be kept in mind that when expressed as JSON, to be sent over the network, the real size is about twice as much, and when saved in the database again there is overhead, such size measures are only approximate and not an exact indication of how much disk space or bandwith a transaction will consume.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

cc001

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 829
    • View Profile
Re: Current 1.7 changelog
« Reply #45 on: November 16, 2015, 10:05:03 am »

Account properties
Those are name / value pairs that can be set on any account (except Genesis), by either the account owner, or by another account. Names are limited to 32 characters, and values to 160 characters. Names are unique per account and per setter account, but not globally unique. Account properties cannot be transferred between accounts. The setter of an account property can edit it by replacing its value with another. Either the setter, or the recipient (if different) of an account property can delete it. There is no limit on the number of properties an account can have. Fee for setting account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee for every 32 chars after that.

What are the use cases for those properties? What was the idea behind them? How can services use them? How are they useful for the regular user with the standard client?
Logged
cc001 Personal - NXT-8RXS-2SSK-RNF2-HSNL8
NxtReporting.com - The Nxt Asset Exchange Portfolio Manager with Profitability Tracking - Donations are greatly appreciated on NXT-5W4G-GAR6-JHJP-H8ZTW

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: Current 1.7 changelog
« Reply #46 on: November 16, 2015, 11:48:22 am »

160 is a magic number indeed. I was initially thinking of 128 only, then decided to make it 32 for free, plus 128 paid, 160 total.
Thanks for explaining.

Quote
But we cannot set the limit to 256 now, and decide to lower it to 128 in the future, this will break client applications.
My thought is that we could tell, from inspecting the block-chain, how much data client apps were actually using. If we reach a point where no app in the last N months has used more than 64 bytes, then we could drop the limit to 128 bytes and be reasonably sure of not breaking them. Technically it is a breaking API change, but one that would not inconvenience anyone in practice. We would also announce now that we planned to do this, so client developers would know that the larger attachments were deprecated and have fair warning.

That said, if the minimum transaction size is 176 bytes, then there are diminishing returns in limiting the attachment size much below that. Someone who actively wants to cause bloat, will get more bloat for their NXT by creating many messages at base cost and size, then by creating fewer with larger attachments. For 5 NXT you could get 5 messages with 32-byte attachments at 208 bytes each = 1040 bytes, or 1 message with 160-byte attachment for 336 bytes total. For this reason it seems to me that allowing larger attachments is actually safe, provided the cost-per-byte is high as planned. Perhaps the limit of 1000 bytes was not wrong; the problem was getting all those bytes for free.

To put it another way, I suspect SuperNet will be screwed by the high fees even if they aren't screwed by a lower limit. Either way, to have a viable service they will need to reduce the size of their permanent attachments.
Logged

BTCDDev

  • Full Member
  • ***
  • Karma: +20/-4
  • Offline Offline
  • Posts: 148
    • View Profile
Re: Current 1.7 changelog
« Reply #47 on: November 23, 2015, 04:10:19 pm »

Will it be possible for each unit of a Singleton asset to be assigned a unique identifier?
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #48 on: November 23, 2015, 04:15:28 pm »

The asset id of each is unique, but manually assign some other identifier, no, there is no field for that.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

BTCDDev

  • Full Member
  • ***
  • Karma: +20/-4
  • Offline Offline
  • Posts: 148
    • View Profile
Re: Current 1.7 changelog
« Reply #49 on: November 23, 2015, 04:27:59 pm »

The asset id of each is unique, but manually assign some other identifier, no, there is no field for that.

Ok. I'm not so familiar with MS, is it possible to do that there?

To issue an asset/currency with each individual unit assigned some uid
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #50 on: November 23, 2015, 05:30:46 pm »

No, there is no way to track units of assets, currencies, or NXT itself. All those are stored as a single number for each, representing the account balance at a given blockchain height, but without possibility to track which coin/asset share came from which transaction.

The closest to what you ask for would indeed be singleton assets, if you assume some convention (not enforced by the core) that all singleton assets issued by a given account and having the same name, represent units of one "asset". However, you could not for example bundle those and put an ask/sell order for a few at a time, the core will still consider each a separate asset.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Damelon

  • Hero Member
  • *****
  • Karma: +792/-54
  • Offline Offline
  • Posts: 2314
    • View Profile
    • Nxt Inside
Re: Current 1.7 changelog
« Reply #51 on: November 24, 2015, 12:39:55 pm »

Account properties
Those are name / value pairs that can be set on any account (except Genesis), by either the account owner, or by another account. Names are limited to 32 characters, and values to 160 characters. Names are unique per account and per setter account, but not globally unique. Account properties cannot be transferred between accounts. The setter of an account property can edit it by replacing its value with another. Either the setter, or the recipient (if different) of an account property can delete it. There is no limit on the number of properties an account can have. Fee for setting account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee for every 32 chars after that.

What are the use cases for those properties? What was the idea behind them? How can services use them? How are they useful for the regular user with the standard client?

I am also looking into these.

Can anyone shed some light on this?
Logged
Member of the Nxt Foundation | Donations: NXT-D6K7-MLY6-98FM-FLL5T
Join Nxt Slack! https://nxtchat.herokuapp.com/
Founder of Blockchain Workspace | Personal Site & Blog

abctc

  • Hero Member
  • *****
  • Karma: +148/-13
  • Offline Offline
  • Posts: 1396
    • View Profile
Re: Current 1.7 changelog
« Reply #52 on: November 24, 2015, 01:49:25 pm »

Account properties
Those are name / value pairs that can be set on any account (except Genesis), by either the account owner, or by another account. Names are limited to 32 characters, and values to 160 characters. Names are unique per account and per setter account, but not globally unique. Account properties cannot be transferred between accounts. The setter of an account property can edit it by replacing its value with another. Either the setter, or the recipient (if different) of an account property can delete it. There is no limit on the number of properties an account can have. Fee for setting account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee for every 32 chars after that.
What are the use cases for those properties? What was the idea behind them? How can services use them? How are they useful for the regular user with the standard client?
I am also looking into these.
Can anyone shed some light on this?
- I think with Account properties and with Account Control (including Phased Txs) it would be possible to make trustless (and even website-less) equivalent of such service as tips.nxtex.info



Just put that profile properties (size of donations, hash of PIN code, tips cookies) into your Account properties.
Logged
Welcome to the Nxt generation of crypto!   Magis quam Moneta (More than a Coin)
"Do not worry, it is an attack" (c) Jean-Luc

Tosch110

  • Hero Member
  • *****
  • Karma: +211/-18
  • Offline Offline
  • Posts: 2365
    • View Profile
Re: Current 1.7 changelog
« Reply #53 on: December 11, 2015, 07:21:56 am »

With the changes of the block algorithm we expect 1440 Blocks a day when I understood that right. That means the maximum leasing range decreases from ~5 weeks to ~2,5.

Can we think about increasing the maximum leasing range?

lurker10

  • Hero Member
  • *****
  • Karma: +168/-33
  • Offline Offline
  • Posts: 1334
    • View Profile
Re: Current 1.7 changelog
« Reply #54 on: December 11, 2015, 08:02:30 am »

With the changes of the block algorithm we expect 1440 Blocks a day when I understood that right. That means the maximum leasing range decreases from ~5 weeks to ~2,5.

Can we think about increasing the maximum leasing range?

+1440

5 weeks is on the borderline of convenience. Forgers will forget or won't bother to renew leases more often if the range is halved weakening security of the blockchain.
Logged
Run a node - win a prize! "Lucky node" project jar: NXT-8F28-EDVE-LPPX-HY4E7

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Current 1.7 changelog
« Reply #55 on: December 11, 2015, 05:12:17 pm »

We will increase the maximum leasing period to 65535 in 1.7, this will be 6.5 weeks.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

lurker10

  • Hero Member
  • *****
  • Karma: +168/-33
  • Offline Offline
  • Posts: 1334
    • View Profile
Re: Current 1.7 changelog
« Reply #56 on: December 11, 2015, 06:06:20 pm »

We will increase the maximum leasing period to 65535 in 1.7, this will be 6.5 weeks.

thank you!
Logged
Run a node - win a prize! "Lucky node" project jar: NXT-8F28-EDVE-LPPX-HY4E7

Tosch110

  • Hero Member
  • *****
  • Karma: +211/-18
  • Offline Offline
  • Posts: 2365
    • View Profile
Re: Current 1.7 changelog
« Reply #57 on: December 12, 2015, 03:18:02 pm »

We will increase the maximum leasing period to 65535 in 1.7, this will be 6.5 weeks.

thank you!

yep, great thing! thanks!

VanBreuk

  • Hero Member
  • *****
  • Karma: +362/-19
  • Offline Offline
  • Posts: 2772
    • View Profile
Re: Current 1.7 changelog
« Reply #58 on: December 12, 2015, 04:07:49 pm »

Account properties
Those are name / value pairs that can be set on any account (except Genesis), by either the account owner, or by another account. Names are limited to 32 characters, and values to 160 characters. Names are unique per account and per setter account, but not globally unique. Account properties cannot be transferred between accounts. The setter of an account property can edit it by replacing its value with another. Either the setter, or the recipient (if different) of an account property can delete it. There is no limit on the number of properties an account can have. Fee for setting account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee for every 32 chars after that.

What are the use cases for those properties? What was the idea behind them? How can services use them? How are they useful for the regular user with the standard client?

I am also looking into these.

Can anyone shed some light on this?

From this thread,

I imagine a single setAccountProperty API which takes a name and a value, similar to aliases but account specific, name unique within the account only, update the value if already existing or delete the name/value pair if value empty. And getAccountProperties which returns all of them for a given account.

Any third party service could add to accounts custom key/value pairs to store relevant info for their service in the Nxt blockchain, with no need of scattering messages around. To use an example in what I know, MGW could for instance work storing deposit addresses as an Account Property, "BTCdeposit":"msigaddr".

When third party developers can assign pairs to existing user accounts (or create new accounts with the value pairs included) and then query those values, this gives the API a good extra of potential usability.
Logged
GPG Fingerprint: B020 D1C1 F289 3B2C 3577  9EAD 455D D175 5913 C7F1
Pages: 1 2 [3]  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly