When sending Ardor to new accounts, the form has a public key field. When I enter the public key and click on Fee calculation there is an error message "Public key announcement attachments not allowed for Ardor transactions". So the field for public key should be removed from the form if it's not allowed to be entered?

It was set to 1440 blocks, I think it is still pending. There are no bundlers now that charge that rate but when I sent it the form gave me that fee to pay and I paid it.

I can't check it now since I'm running 2.0.1e which rolled back the database. I'll see if I can create a poll on the new release.

I created a poll on 2.0.1e on the IGNIS chain. The calculated fee was 1 IGNIS. This is correct since poll creation costs 10 ARDR and the bundler rate was 0.1.

I did it again, tx is pending on the Ignis chain. To reproduce:

1) start a bundler with a smaller rate than the market's;2) getBundlerRates (and minimum fee calculation) now fetches this new rate;3) stop the bundler to imitate bad network connectivity or attack to make the bundler unreachable;4) waiting 10 minutes to get into the next 10-minute window doesn't seem to make a difference because:5) clicking on create a poll (probably other transaction types too), clicking on fee calculation, user will get the stopped bundler's fee, the same as in step 2. User doesn't know the bundler is unreachable and does not adjust the fee higher;6) user submits transaction and waits and waits and waits but tx doesn't confirm;

In real life someone could start a bundler to pick pending transactions from the mempool if they stay there too long and if it's slightly profitable or subsidize.Will a much better solution not be for the next best bundler rate to show up after some reasonable time for getBundlerRates (and minimum fee calculation) even though no new bundler in the network was started after the failed bundler had stopped? I've checked and 30 minutes later it's still the stopped bundler's rate being fetched, everyone will now submit txs and pay that inadequate fee.Can a Replace-by-fee feature be one of solutions to this? I know you said the minBundlerBalanceFXT in the config will mitigate the effect to some extent but it means users have to always keep it high and miss on getting possibly better rates from smaller stake bundlers. Is it possible to make this setting dynamically configured in settings in the browser or somehow allow user to see other rates in the UI fee calculation? Is this a non-issue?

First one: If there are no bundlers in IGNIS, who is doing the child block transactions?At this moment there are no bundlers in Settings/Bundlers, but there are child block transactions... For example, if I buy one Alias, the transaction is confirmed without Bundlers on list on Settings/Bundlers, or Settings/Bundlers only list the own Bundlers?

Second one: In Child chains details there is Bundling Rate value, Is this value fixed? It seems that is the maximum rate that bundlers can set.

He said:If there are no bundlers not one is doing the bundling. The transaction will stay in the unconfirmed pool until it expires.Currently, the bundlers page only shows your bundlers not all bundlers.

The chain properties modal shows the best available rate but does not show what the maximum Ardor fee this bundler is willing to pay and if this bundler is even online

It was set to 1440 blocks, I think it is still pending. There are no bundlers now that charge that rate but when I sent it the form gave me that fee to pay and I paid it.

I can't check it now since I'm running 2.0.1e which rolled back the database. I'll see if I can create a poll on the new release.

I created a poll on 2.0.1e on the IGNIS chain. The calculated fee was 1 IGNIS. This is correct since poll creation costs 10 ARDR and the bundler rate was 0.1.

I did it again, tx is pending on the Ignis chain. To reproduce:

1) start a bundler with a smaller rate than the market's;2) getBundlerRates (and minimum fee calculation) now fetches this new rate;3) stop the bundler to imitate bad network connectivity or attack to make the bundler unreachable;4) waiting 10 minutes to get into the next 10-minute window doesn't seem to make a difference because:5) clicking on create a poll (probably other transaction types too), clicking on fee calculation, user will get the stopped bundler's fee, the same as in step 2. User doesn't know the bundler is unreachable and does not adjust the fee higher;6) user submits transaction and waits and waits and waits but tx doesn't confirm;

In real life someone could start a bundler to pick pending transactions from the mempool if they stay there too long and if it's slightly profitable or subsidize.Will a much better solution not be for the next best bundler rate to show up after some reasonable time for getBundlerRates (and minimum fee calculation) even though no new bundler in the network was started after the failed bundler had stopped? I've checked and 30 minutes later it's still the stopped bundler's rate being fetched, everyone will now submit txs and pay that inadequate fee.Can a Replace-by-fee feature be one of solutions to this? I know you said the minBundlerBalanceFXT in the config will mitigate the effect to some extent but it means users have to always keep it high and miss on getting possibly better rates from smaller stake bundlers. Is it possible to make this setting dynamically configured in settings in the browser or somehow allow user to see other rates in the UI fee calculation? Is this a non-issue?

A bundler rate expires after 60 minutes. The idea is that bundlers are long running. Even if there was a bundler stopped message, this wouldn't guarantee that the bundler rate would be removed since I suspect that most people stop a node by simply stopping the Java virtual machine without first stopping each bundler and forger.

The 60-minute expiration is an arbitrary value and could be changed. But it would have to be on a network basis and not a node basis since the renewal message wouldn't be sent until the bundler node decided the rate had expired.

All of the bundler rates are available internally, so an API could be added to retrieve all of them. I'll ask if this is something that should be added to the UI.

What we could do is add a checkbox "pay fee in ARDR", which after creating the transaction will automatically use the bundleTransactions API to bundle it too, the user acting as a one-time bundler for his own transaction, paying the minimum fee required in ARDR. Not sure how easy this would be client-side.

Then if there is actually another bundler running, it will bundle this and other child transactions if present, and the resulting child block will be preferred by forgers as having higher total fee, so the one that the user created will just expire. If there are no other bundlers running at that rate, it will be accepted.

Or, for unconfirmed transactions we can add a "Bundle" action. If you are seeing a transaction stay unconfirmed too long, this could be used to create a bundling transactions for it only.

Or, for unconfirmed transactions we can add a "Bundle" action. If you are seeing a transaction stay unconfirmed too long, this could be used to create a bundling transactions for it only.

The tx fee has to be paid in ARDR though which user may not have? Can it be made such that anyone can resubmit the same transaction and pay additional fees in CC tokens? If not anyone, then the same user to sign with the same private key?

Or, for unconfirmed transactions we can add a "Bundle" action. If you are seeing a transaction stay unconfirmed too long, this could be used to create a bundling transactions for it only.

The tx fee has to be paid in ARDR though which user may not have? Can it be made such that anyone can resubmit the same transaction and pay additional fees in CC tokens? If not anyone, then the same user to sign with the same private key?

What this would do is create a one-transaction child chain block, so anyone who has ARDR could do it.

Or, for unconfirmed transactions we can add a "Bundle" action. If you are seeing a transaction stay unconfirmed too long, this could be used to create a bundling transactions for it only.

The tx fee has to be paid in ARDR though which user may not have? Can it be made such that anyone can resubmit the same transaction and pay additional fees in CC tokens? If not anyone, then the same user to sign with the same private key?

What this would do is create a one-transaction child chain block, so anyone who has ARDR could do it.

Anyone with ARDR may not want to do it because of low or negative profitability.The requirement for the user to have ARDR for this special case is not unlike the requirement to have NXT to send a MS currency transaction which is one of the problems Ardor is trying to solve. I just want to convince to make usability a little easier if it is possible.The current design is such that it is unknown if the transaction will be promptly processed with the minimum fee, any measures to help it will be met with enthusiasm.

How about if the UI has two buttons: 'Calculate minimum' and 'Calculate an average' fee (from N number of best rate bundlers), user can decide if it's worth the waiting risk to pay only the minimum or have a better guarantee paying a higher average - but user needs to know how much that average is to avoid overpaying too much?

The 'bundle' button for owners of ARDR tokens is great and should be done too.

For the UI, maybe something like 3 radio buttons (low-normal-high priority) filled with the 3 best successive bundlers' fees to let user make an informed decision on what fee to pay. This is a problem in Bitcoin right now, some client software can't calculate the right fee, there are lots of user complaints.

I just want to convince to make usability a little easier if it is possible.The current design is such that it is unknown if the transaction will be promptly processed with the minimum fee, any measures to help it will be met with enthusiasm.

Just let the forgers bundle the childchain transactions and we will have best usability without all this rates, fees and bundlers nonsense.

Paying dividends.Total number of units is 1000, 2 decimals, one user got 100 units, I want to pay him dividends, holding type: asset, 1 per share.In the dividend payment form, when I put 1 in the Amount per Share, I get "A total of 10000000000000000 6025948372952594856 translation:shares will be distributed among 1 accounts which own a total of 100 shares."Clicking on Submit "Failed to broadcast transaction: Insufficient balance".Looks like a bug, as I only want to send out 100 to him, my issuer account has that much.If I type 2 per share, "A total of 20000000000000000 6025948372952594856 translation:shares will be distributed among 1 accounts which own a total of 100 shares."