Topic: Release information - page 2. (Read 10921 times)

I was also not able to verify using Chrome.

Edit: I even downloaded the release text but it doesn't work when I download it either.

Well investigated !

I'll make sure I do not put any trailing spaces in the release.txt in future.

Curiously, on Safari it works. Firefox trims the whitespace before the line breaks:

Line breaks indicated by "$"

Does anyone else see this behaviour? The solution would be not to have trailing white space in the announcement, which could be quite annoying to check.

It is one of the standard features in the installer creator I use. I must admit I never really use it.

I checked it using Safari on a Mac - check that the last character is the 'm' of Jim. It is easy to add an extra line break at the end.

create auto-installation script? what is it?...advanced use only I suppose for future releases im guessing

FYI: When I copy the release information from Firefox into MultiBit the signature cannot be verified (on MacOS). Could be due to line breaking?!

-----BEGIN BITCOIN SIGNED MESSAGE-----
There is a new release of MultiBit at:
https://multibit.org

Version 0.5.13

Changes:
#190. The backing up of wallets has been improved.
      There is now a data directory for each wallet.

#111. Failing test fixed. Also fixed functional tests.
#174. Send address is properly trimmed.
#182. Swiss Francs now has correct currency prefix.
#189. Receiving addresses that are manually added to the info file do not appear in the UI.
#191. Swahili added as a target language.
#195. Fixed Verify Message tooltip on a Mac.
#201. Fixed blank validation message if fee takes total over amount in wallet.

Release checklist:
https://multibit.org/test/releaseCheckList-0.5.13.jpg


Bitcoin signing:
This message text (starting with "There is a new release" and ending with "Jim")
is Bitcoin signed with the https://multibit.org donation address.


SHA256 hashes for files:
aaaad8848e69aca528567dfc8ef879a76cb007fd8649ca1baa1c9ff7829c32b9  multibit-0.5.13-linux.jar
64b62ed86bcab0b56cb15670e9504e2bb7a5420c9e3879caeaadbc9f3762248a  multibit-0.5.13-linux.jar.asc
da47611fa8ae82627db93de1d69ba439dce520d05abe62b35ef1be7116eda905  multibit-0.5.13-windows.exe
ce4ba37887a094717982b80351ae0dc3468ff8b134aecfea9708a3f01bcd78c1  multibit-0.5.13-windows.exe.asc
1b3c975ea4b4abf616b8ae6ecd115c6ece95fcdd448d16e5cefbf3c5f1c207e6  multibit-0.5.13.dmg
a92e2c98d0f90f63faed53e21356bb890db82ccd55390fec92a795d64d4ffa4b  multibit-0.5.13.dmg.asc
978369211040430b64364b4a289abf37a6a8d0d667375140f91252d2273f9fc2  multibit-exe.jar
7293ffbbff8c5673d719ad5042d1d3b5c1d9904102ce73397b726c5c53b0d124  multibit-exe.jar.asc
0294dad7f93721c2550c4c483940c40499cdcd6d249636728d975081ca638b01  multibit.exe
676db0e0ec814e3cc048c4cc406947a961b16d1b2dd46c91e94ad86c70efb309  multibit.exe.asc


PGP signing:
You can verify the PGP signatures by installing gpg and importing the key id 0x79F7C572
from http://pgp.mit.edu. The files are signed with the subkey with id 0x23F7FB7B.

Jim
-----BEGIN BITCOIN SIGNATURE-----
Version: Bitcoin-qt (1.0)
Address: 1AhN6rPdrMuKBGFDKR1k9A8SCLYaNgXhty

HFtPFVkjPBWmDj1Btw/xQ+wlML+NBTunvXURBBOaNvxrSjHFMQGNxB6frFTmW8qQhBOBxuQqEOkazt18KfmyRpE=
-----END BITCOIN SIGNATURE-----

I just checked on blockchain.info.
As I type there are about 2500 transactions 'hanging around' unconfirmed.

The miners seem to cap their blocks at just under 250KB, clearing  about 500 transactions each block.

Network is busy, transactions stack up, miners are not clearing them by putting them in blocks

Hi gotpetum,

The blockchain.info estimates can be a bit larger than things actually take.
Would be interested to see how much time/ how many blocks your tx actually takes for its first confirmation.

Thanks for working on principled solutions that will elegantly handle the edge cases, jim618 :-)

In the meanwhile...

Fees    0.0001 BTC
Estimated BTC Transacted    0.781 BTC
Estimated Confirmation Time    12 hours (queue position 3002)

:-P

Hi Chooseusername, HostFat,

No problem at all - I thought I would reply in detail as the technical details aren't at all obvious. Fees have become a little complicated and I expect they will change again in the future.

Bitcoin is an experiment after all !

I think you are right that there is still something missing though in that the user DOES want to change the fee sometimes according to the priority of the transaction. Simply having a computed value and not being able to change it does not feel right.

For instance if I am moving money around my own wallets/ amoungst friends it does not matter if it takes a little longer. But if I am in a coffee shop sending money to someone (eg localbitcoins) then I would probably increase the fees paid so that it will (almost certainly) get in the next block as we both save time. Or the payment might be important/ urgent for some other reason.


One of the parameters in the feesolver is "fee per kilobyte of transaction" so that seems like a good candidate for tweaking. It is hardwired at 0.001 BTC / KB at the moment but it might be worth making this something the user can set in the Preferences. Of course it is a little more work but that might be the way to go.

That way users still have control over what they want to set (tx urgency/ priority) but don't have to worry about all the fee rules.

Well, you're right. I'm sorry for my ignorance and thank you for detailed explanation.

I appreciate what you are saying but it is just more complicated than that.

Say you increase the calculated fee. That needs paying for so you may need to bring in another tx input to spend. So now the tx is bigger. Maybe it needs MORE fee because it has slipped over a 1000 byte limit. So you try adding MORE tx inputs. But if you only have dust remaining in your wallet you can be worse off in that the tx inputs you just added are worth less than the extra fee you need to pay for adding them. You had a good tx with the smaller fee but cannot find a tx providing the increased fee.

Or maybe the new change amount you've created is under the new limit for small tx outputs - 5430 is it or is it 5340 satoshi ? Best write it down as you'll need to manually check that after you made the change to your fee - that small amount should get added to your fee to eliminate the small output. So you've eliminated a tx output so now the tx is smaller. So now you can possibly have a smaller fee to get the same effect as you had before you changed the fee. Do you want the option to rechange the fee a second time ?

Honestly have a look at the code I pointed to about calculating a fee.
Of course it is your bitcoin but it is now impractical to work out the right fee manually.

A 'bad' fee means your tx either cannot be constructed (immediate fail), does not propagate (obviously bad but worse because then any change won't be spendable - very unpopular) or your tx takes ages to confirm (equally unpopular).

Sticking on 0.5.11 means you may create tx that don't propagate or take ages to confirm. It is your choice of course but my aim is to get people's transactions out in the network, propagated and confirmed as painlessly as possible for everyone.

I agree with this.
You can even add an advanced option to enable this possibility if you want, but I think that it's really needed.
I also want to be able to chose/change the fee.

To make my transactions being processed fast in cause of %whatever_happened%, for example. And because it's my money and I want to control it by myself, not by algorythm. And at last because I can. So, I'll stick with 0.5.11, I guess. It's your program of course, and you choose how to develop it, but why make slider, why not just field pre-filled with automatically calculated fee which I can change? Why you disable me to change fees? I'm not a new user, I can worry about fees by myself.

Yes it's time to find the miners who are still doing that and ask them to reconsider.

Hi Mike,

I think what's happening is:

1) Currently the 'general' fee for a < 1KB tx in BitcoinLand is 0.0005 BTC. This is my estimate from having a look at the tx in the live stream on the blockchain.info home page.
2) MultiBit 0.5.12, Andreas's Wallet v3.0.9 and Bitcoin-QT 0.8.2/3 have moved to lower fees of 0.0001 BTC for the first KB.
3) Generally tx seem to get 'serviced' in order of creation but when there is a big gap between blocks the unconfirmed tx start piling up.
4) Miners seem to be using a soft limit of 250 KB so they naturally put in the juiciest tx into their block. They clear about 600 of the tx from the unconfirmed pool for each block.

If the next block also takes an above average time to solve then the low-fee-tx can continue to get bumped by juicier tx that appear.

I have suggested to the other alt client devs that they have a *great* opportunity to save their users cash and drop their calculated fees to match the Bitcoin-QT fees. It is a bit of a Prisoner's Dilemma - I think Electrum tried to drop their fees to 0.0001 BTC / KB about a month ago but had to increase them again as no-one else did.


I think if/once most clients match the Bitcoin-QT fee structures the current soft limit on blocks will be sufficient - I think the miners are processing same-fee tx by age first (which effectively makes it first-transmitted-first-served).

It's a pretty interesting dynamic system the whole area of fees I must admit.

If people's transactions are getting bumped we should ask miners to increase their soft block size limits again.

@Chooseusername
I am interested in why exactly you want to set a specific fee. Is the calculated one causing you problems ?