Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: Gavin Andresen on May 10, 2013, 03:41:52 PM



Title: 0.8.2rc1 ready for testing
Post by: Gavin Andresen on May 10, 2013, 03:41:52 PM
Bitcoin-Qt version 0.8.2 release candidate 1 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/test/

This is a maintenance release that fixes many bugs and includes
a few small new features.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues


How to Upgrade

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you
run 0.8.2 your blockchain files will be re-indexed, which will take
anywhere from 30 minutes to several hours, depending on the speed of
your machine.

0.8.2 Release notes

Fee Policy changes

The default fee for low-priority transactions is lowered from 0.0005 BTC
(for each 1,000 bytes in the transaction; an average transaction is
about 500 bytes) to 0.0001 BTC.

Payments (transaction outputs) of 0.543 times the minimum relay fee
(0.00005430 BTC) are now considered 'non-standard', because storing them
costs the network more than they are worth and spending them will usually
cost their owner more in transaction fees than they are worth.

Non-standard transactions are not relayed across the network, are not included
in blocks by most miners, and will not show up in your wallet until they are
included in a block.

The default fee policy can be overridden using the -mintxfee and -minrelaytxfee
command-line options, but note that we intend to replace the hard-coded fees
with code that automatically calculates and suggests appropriate fees in the
0.9 release and note that if you set a fee policy significantly different from
the rest of the network your transactions may never confirm.

Bitcoin-Qt changes

* New icon and splash screen
* Improve reporting of synchronization process
* Remove hardcoded fee recommendations
* Improve metadata of executable on MacOSX and Windows
* Move export button to individual tabs instead of toolbar
* Add "send coins" command to context menu in address book
* Add "copy txid" command to copy transaction IDs from transaction overview
* Save & restore window size and position when showing & hiding window
* New translations: Arabic (ar), Bosnian (bs), Catalan (ca), Welsh (cy),
  Esperanto (eo), Interlingua (la), Latvian (lv) and many improvements
  to current translations

MacOSX:
* OSX support for click-to-pay (bitcoin:) links
* Fix GUI disappearing problem on MacOSX (issue #1522)

Linux/Unix:
* Copy addresses to middle-mouse-button clipboard


Command-line options

* -walletnotify will call a command on receiving transactions that affect the wallet.
* -alertnotify will call a command on receiving an alert from the network.
* -par now takes a negative number, to leave a certain amount of cores free.

JSON-RPC API changes

* listunspent now lists account and address infromation.
* getinfo now also returns the time adjustment estimated from your peers.
* getpeerinfo now returns bytessent, bytesrecv and syncnode.
* gettxoutsetinfo returns statistics about the unspent transaction output database.
* gettxout returns information about a specific unspent transaction output.


Networking changes

* Significant changes to the networking code, reducing latency and memory consumption.
* Avoid initial block download stalling.
* Remove IRC seeding support.
* Performance tweaks.
* Added testnet DNS seeds.

Wallet compatibility/rescuing

* Cases where wallets cannot be opened in another version/installation should be reduced.
* -salvagewallet now works for encrypted wallets.


Thanks to everybody who contributed to the 0.8.2 release!

APerson241
Andrew Poelstra
Calvin Owens
Chuck LeDuc Díaz
Colin Dean
David Griffith
David Serrano
Eric Lombrozo
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Jonas Schnelli
Larry Gilbert
Luke Dashjr
Matt Corallo
Michael Ford
Mike Hearn
Patrick Brown
Peter Todd
Philip Kaufmann
Pieter Wuille
Richard Schwab
Roman Mindalev
Scott Howard
Tariq Bashir
Wladimir J. van der Laan
freewil
gladoscc
kjj2
mb300sd


Title: Re: 0.8.2rc1 ready for testing
Post by: John (John K.) on May 10, 2013, 03:47:36 PM
Stickied.


Title: Re: 0.8.2rc1 ready for testing
Post by: WikileaksDude on May 10, 2013, 05:02:24 PM
Keep calm and Test.

Brutal effort on this 0.8.2 release.


Title: Re: 0.8.2rc1 ready for testing
Post by: vindimy on May 10, 2013, 05:45:07 PM
Will be testing it on my home PCs and servers.

Thanks to devs for the work they put in and the shit they put up with. Especially the shit.


Title: Re: 0.8.2rc1 ready for testing
Post by: Searinox on May 10, 2013, 05:58:14 PM
Deployed and mining. I understand the risks and I've backed up my wallet. I just want to see how this affects my p2pool mining latency.


Title: Re: 0.8.2rc1 ready for testing
Post by: mc_lovin on May 10, 2013, 06:36:57 PM
The most crucial version ever? :) 

Hopefully this all goes smoothly!


Title: Re: 0.8.2rc1 ready for testing
Post by: twobits on May 10, 2013, 06:47:00 PM
So no changes that might fix reliability of the index then?


Title: Re: 0.8.2rc1 ready for testing
Post by: davout on May 10, 2013, 06:50:06 PM
* -walletnotify will call a command on receiving transactions that affect the wallet.
Nice !


Title: Re: 0.8.2rc1 ready for testing
Post by: gmaxwell on May 10, 2013, 06:50:41 PM
So no changes that might fix reliability of the index then?
In particular, two bugs were fixed that would cause crashes and might have cause database corruption on Windows (problem with multiple open files) and MacOSX (running out of file descriptors). These may fix or at least improve the leveldb database reliability problems on these two platforms but we're not sure.

Feedback on the RC here would be helpful. E.g. "I had crashes and index corruption on $operatingsystem before and I am (not) still having them."


Title: Re: 0.8.2rc1 ready for testing
Post by: twobits on May 10, 2013, 06:53:07 PM
So no changes that might fix reliability of the index then?
In particular, two bugs were fixed that would cause crashes and might have cause database corruption on Windows (problem with multiple open files) and MacOSX (running out of file descriptors). These may fix or at least improve the leveldb database reliability problems on these two platforms but we're not sure.

Feedback on the RC here would be helpful. E.g. "I had crashes and index corruption before and I am (not) still having them."

All right, because 0.8.1 has been usable for me, so I was disappointed to see nothing that indicated fixes in the changes posted.

https://bitcointalk.org/index.php?topic=184125.0




Title: Re: 0.8.2rc1 ready for testing
Post by: Caesium on May 10, 2013, 06:55:41 PM
* Fix GUI disappearing problem on MacOSX (issue #1522)

Confirm this works, that used to be really annoying, thanks.

It's still not perfect; I have "Minimize windows into application icon" enabled, and if you minimise the window then click on the app dock icon it doesn't un-minimise it whereas other apps do. You need to select Show/Hide from the menu to see it again with Bitcoin-QT. But at least it's not possible to get stuck in a situation where you can't see the UI anymore.


Title: Re: 0.8.2rc1 ready for testing
Post by: bx5a on May 10, 2013, 08:11:17 PM
* Fix GUI disappearing problem on MacOSX (issue #1522)

Confirm this works, that used to be really annoying, thanks.

It's still not perfect; I have "Minimize windows into application icon" enabled, and if you minimise the window then click on the app dock icon it doesn't un-minimise it whereas other apps do. You need to select Show/Hide from the menu to see it again with Bitcoin-QT. But at least it's not possible to get stuck in a situation where you can't see the UI anymore.

Confirming the minimization issue.


Title: Re: 0.8.2rc1 ready for testing
Post by: rme on May 10, 2013, 09:04:28 PM
Good update, welcome the 0.0001 fee ;)


Title: Re: 0.8.2rc1 ready for testing
Post by: molecular on May 10, 2013, 09:08:42 PM
I used newest git and recompiled. "About" says v0.8.0-318-g8c6bbb3-beta. That ok?



Title: Re: 0.8.2rc1 ready for testing
Post by: zvs on May 10, 2013, 09:50:23 PM
nm, fixed.   ;D


Title: Re: 0.8.2rc1 ready for testing
Post by: morningtime on May 10, 2013, 09:51:43 PM
Looks good!


Title: Re: 0.8.2rc1 ready for testing
Post by: GrapeApe on May 10, 2013, 10:21:34 PM
Deployed and mining. I understand the risks and I've backed up my wallet. I just want to see how this affects my p2pool mining latency.

When I start it up there is a message that says not to be used for mining. Can someone tell me why?


Title: Re: 0.8.2rc1 ready for testing
Post by: Pieter Wuille on May 10, 2013, 11:31:31 PM
When I start it up there is a message that says not to be used for mining. Can someone tell me why?

Non-release builds carry that warning (and this is just release candidate).


Title: Re: 0.8.2rc1 ready for testing
Post by: fornit on May 11, 2013, 12:26:34 AM
works fine on win7 64bit.
either i got a lucky first connection or network is much improved. DL for 10 hours of blocks was less than a minute from startup, with 4x3ghz phenom cpu at 75% load (blockchain on ssd). so it might actually have been the cpu bottlenecking, which would be a pretty awesome improvement. (and new work for the developers *g*)


Title: Re: 0.8.2rc1 ready for testing
Post by: gmaxwell on May 11, 2013, 02:41:49 AM
(and new work for the developers *g*)
Pieter already has new signature validation code that speeds up the cpu bound part of recent chain syncup by 6x on 64-bit. It's just going to take a lot of testing and review before it can be integrated.


Title: Re: 0.8.2rc1 ready for testing
Post by: keystroke on May 11, 2013, 04:46:41 AM
Starts up fine under Windows 8 x64.


Title: Re: 0.8.2rc1 ready for testing
Post by: rme on May 11, 2013, 08:02:17 AM
Testnet splash screen:
https://i.imgur.com/OkfeRQ7.png

Cool  ;D


Title: Re: 0.8.2rc1 ready for testing
Post by: slothbag on May 11, 2013, 12:47:24 PM
Works fine for me on Win8 64bit.  Startup time seems greatly improved which is nice.

Splash screen behaves a little nicer than the previous one.

Great work.


Title: Re: 0.8.2rc1 ready for testing
Post by: CryptoPath on May 11, 2013, 11:48:41 PM
Is there a risk for a new fork chain ?


Title: Re: 0.8.2rc1 ready for testing
Post by: gmaxwell on May 12, 2013, 12:30:00 AM
Is there a risk for a new fork chain ?
0.8.2 does not obviously have any high consensus-consistency risk changes.


Title: Re: 0.8.2rc1 ready for testing
Post by: keystroke on May 12, 2013, 04:48:53 AM
Working great so far, I'm just leaving it running. I guess we will get a release before the 15th?


Title: Re: 0.8.2rc1 ready for testing
Post by: Searinox on May 12, 2013, 06:29:41 PM
2 days of solid running, 1 instance of qt another of bitcoind, both mining P2Pool on different machines, ATI and nVidia respectively. No crashes, abnormal latency, slow response or anything of the sort. Both machines are running Windows 7 x64 SP1 + all updates.


Title: Re: 0.8.2rc1 ready for testing
Post by: Kupsi on May 12, 2013, 08:17:33 PM
Works fine on my Win 7 64 bit. And now I have over 63 connected nodes  :D

Thank you for great work again.


Title: Re: 0.8.2rc1 ready for testing
Post by: jdbtracker on May 12, 2013, 11:13:16 PM
hey just for fun I decided to do a little math and see how much this change would gain the network.

61883 transaction per 24 hour cycle

times .0001 x 120USD/BTC = 742USD/day as it stands now

742USD/day  divided by 24 hours divide that by 6 blocks/hour  = 5.15USD/block divided by .012c/kb= 429kb of transactions

61883/24/6= 429 transactons/block

wow! are people all sending 1kb transactions today?!

LOL!

Now this has me curious, what kind of scale of transactions is the maximum number of transactions

2898 transactions per hour

29,891 BTC sent per hour

120USD/BTC

.17mb / block transaction average

 thats 174kb

 0.36kb/transaction,

so dividing 500kb/.36 = 1388 maximum transations per block =  200,000 maximum transactions per day
x
.0001BTC(.012 cents)

that's 19.9872BTC/day x 120USD=2398.464USD/Day payed in fees

x
.0083BTC(.996 dollars)

thats 1660BTC/Day x 120USD = 200,000USD/Day yeah more or less correct


wow it would be nutty to think that might be possible one day, but the size of some transactions is enormous!
Holy how much are they transferring?

by the way, works great on p2pool windows 7 x64


Title: Re: 0.8.2rc1 ready for testing
Post by: mikeg on May 13, 2013, 02:01:30 AM
Initial test results:

Code:
OS: Ubuntu 12.04 LTS 64-bit
Memory: 3.9GB
Processor: Intel Core2 Quad CPU Q8200
Graphics: Vesa Cypress

01) >cp ~/.bitcoin .bitcoin-bak
02) >rm .bitcoin/wallet.dat
03) >rm .bitcoin/addr.dat
04) Built bitcoind, bitcoin-qt
05) Launched bitcoin-qt: [Error:Invalid amount for -mintxfee=<amount>:'0.00000000']
06) >rm .bitcoin/bitcoin.conf
07) Launched bitcoin-qt
---> 8:17pm, Verifying Blocks
---> 8:18pm, Rescanning [no indication anything is happening]
---> 8:24pm, Main Wallet Screen [2 hours behind blockchain]
---> 8:25pm, Sync [OK]
08) quit bitcoin-qt
09) >cp ../.bitcoin-bak/addr.dat .
10) Launched bitcoin-qt, addresses not available
11) Quit bitcoin-qt
12) >cp ../.bitcoin-bak/wallet.dat .
13) Launched bitcoin-qt, addresses and previous balance [OK]
14) Quit bitcoin-qt
15) Launched bitcoind [ran a few commands, OK]
16) Built bitcoin, bitcoin-qt tests
17) ./test_bitcoin [Running 93 test cases... *** No errors detected]
18) ./bitcoin-qt_test [Config: Using QTest library 4.8.1, Qt 4.8.1 -- Totals: 3 passed, 0 failed, 0 skipped]


Title: Re: 0.8.2rc1 ready for testing
Post by: saddambitcoin on May 13, 2013, 02:16:16 AM
I'm not sure that I like the Bitcoin logo changing color from a pleasant gold to darker orange, reminds me of the color of Triaminic syrup.


Title: Re: 0.8.2rc1 ready for testing
Post by: gmaxwell on May 13, 2013, 04:03:20 AM
09) >cp ../.bitcoin-bak/addr.dat .
10) Launched bitcoin-qt, addresses not available
Addr.dat has nothing to do with bitcoin addresses. It was a file the older versions of Bitcoin used to keep track of peers. The name refers to IP network addresses. The functionality was replaced by peers.dat several versions ago and current software doesn't read addr.dat at all, so your results there are completely expected.


Title: Re: 0.8.2rc1 ready for testing
Post by: jl2012 on May 13, 2013, 04:14:05 AM
Is there a risk for a new fork chain ?
0.8.2 does not obviously have any high consensus-consistency risk changes.

People thought the same when 0.8 was released.  ;)

EDIT: this comment is not accurate. see below


Title: Re: 0.8.2rc1 ready for testing
Post by: gmaxwell on May 13, 2013, 06:29:30 AM
People thought the same when 0.8 was released.  ;)
Uh. No. That is entirely untrue. The database and blockchain engine was completely rewritten and, in fact, we had considered releasing 0.8.0 as "not for use by miners". Several severe chain splitting bugs had been introduced in the coarse of 0.8's development and corrected prior to release.   Obviously it wasn't know that there were outstanding ways of trigger inconsistency, but it was certainly known that there were higher risk changes. Please don't rewrite history just to create a forum quip.

Of course, its not possible to be certain that something is bug free: Surprising things happen. But thats why I answered that there were no known high risk changes, rather than responding that there was no risk.


Title: Re: 0.8.2rc1 ready for testing
Post by: LightRider on May 13, 2013, 07:14:01 AM
Splash screen does not indicate that bitcoin is now under the microtransaction hating iron fisted tyrannical rule of Gavin the Merciless. Otherwise, works ok.

Thanks devs!


Title: Re: 0.8.2rc1 ready for testing
Post by: keystroke on May 13, 2013, 04:24:44 PM
The "Pay transaction fee" dialog box defaults to a 0.00100000 fee if the up arrow is clicked. It still allows entering a 0.00000001 fee manually. This makes sense as the default policy can be overridden. However perhaps the dialog box should have information about the default fee and how fees are calculated? Or a pop-up to warn if the fee used is too low?


Title: Re: 0.8.2rc1 ready for testing
Post by: jdbtracker on May 13, 2013, 05:23:51 PM
Had a crash in Windows 7 x64 fully updated. running p2pool 11.4, I close p2pool and Bitcoind crashes. Just testing on a new build.


Title: Re: 0.8.2rc1 ready for testing
Post by: jgarzik on May 13, 2013, 08:07:16 PM
The "Pay transaction fee" dialog box defaults to a 0.00100000 fee if the up arrow is clicked. It still allows entering a 0.00000001 fee manually. This makes sense as the default policy can be overridden. However perhaps the dialog box should have information about the default fee and how fees are calculated? Or a pop-up to warn if the fee used is too low?

There is near-universal agreement that the fee system -- its calculation, presentation to users, and other details -- are in need of revision.  That is one of the goals of 0.9, hopefully.



Title: Re: 0.8.2rc1 ready for testing
Post by: jdbtracker on May 13, 2013, 08:50:46 PM
I'm only a new user, just found out about it from my boss who wanted me to check Bitcoin out see what I thought about it.

but for these features that your talking about they should be up-front in the client, so people can change them on the fly, just like Facebook.

Everyone has seen Facebook, it does everything that e-mail does, it's just in your face, transfer pictures, text,files, etc and make it easy to adjust; A minimum clicks per feature approach. Let the Bitcoin users have easy access in their face to these features.

e.g. put the transaction fee/kb in the front, so it is a visible and changeable on the fly variable.
       when sending a transaction, list the Kb size of that transaction so people know how much they should actually put as a fee; right now people are just guessing and hoping... trial and error on the part of the user = frustration.
      also can it somehow be listed in the client before sending a transaction the likelihood of it being included in the next block according to the fee provided? This can create a market feedback loop as to how fast they want that transaction in the block.

I think the more info the relevant users have in front of them the more likely they will react intelligently to changes in the network.


Title: Re: 0.8.2rc1 ready for testing
Post by: IVIasterZox on May 14, 2013, 01:36:02 PM
Looks verry Good !!!

But why did not you implement Coincontroll?
I wait for this ....


Title: Re: 0.8.2rc1 ready for testing
Post by: BitSlut69 on May 16, 2013, 05:43:48 PM

The default fee for low-priority transactions is lowered from 0.0005 BTC
(for each 1,000 bytes in the transaction; an average transaction is
about 500 bytes) to 0.0001 BTC.


Won't that cause old clients, which will comprise the majority of the network, to ignore and not propagate transactions from the new client that only have .0001 BTC fees?


Title: Re: 0.8.2rc1 ready for testing
Post by: DeathAndTaxes on May 16, 2013, 05:47:39 PM

The default fee for low-priority transactions is lowered from 0.0005 BTC
(for each 1,000 bytes in the transaction; an average transaction is
about 500 bytes) to 0.0001 BTC.


Won't that cause old clients, which will comprise the majority of the network, to ignore and not propagate transactions from the new client that only have .0001 BTC fees?

Existing client will relay low priority txs with a fee of 0.0001 but wont' allow you to create a new (low priority) tx without a fee of at least 0.0005.  This rule change should simplify things.  Understand however that miners are free to impose whatever fee requirements they like so a tx (low priority or high) with a fee of only 0.0001 BTC may wait a while before inclusion in a block.


Title: Re: 0.8.2rc1 ready for testing
Post by: gmaxwell on May 16, 2013, 05:49:04 PM
Won't that cause old clients, which will comprise the majority of the network, to ignore and not propagate transactions from the new client that only have .0001 BTC fees?
No, when the 0.0005 base for non-free transactions was instituted the relay of 0.0001/kb (but not mining) transactions were permitted in anticipation of potential future reductions.


Title: Re: 0.8.2rc1 ready for testing
Post by: keystroke on May 17, 2013, 02:21:40 PM
Any word when this will be final? I don't see any changes in github for awhile now. Is the plan to release it during the conference?


Title: Re: 0.8.2rc1 ready for testing
Post by: ISAWHIM on May 18, 2013, 07:45:58 AM
Is this version still seeing "merged transactions" as separate transactions for calculating the "minimum fee"...

The prior version was seeing things like this...

Example only... (min fee 0.0005)

{Attempting to send 0.000018506, pulled from many "partial amounts"}
ldfjslkfj 0.000000123 ->
sfoisud 0.000018273 ->
osidufo 0.000000010 ->
doifusid 0.000000100 -> = dkfjsldk [0.000018506] @ fee (0.0005 x 4):[0.00200000] = -0.002018506 total deduction.

Fees get real large, with up to 100 partial "change" mergers into one singular transaction. (Eg, it is treating every change-packet as a separate transaction, though it is simply merging them into ONE singular transaction... thus, expected payment would be 0.0005 not 0.0005x4 = 0.0020...


Title: Re: 0.8.2rc1 ready for testing
Post by: Akka on May 18, 2013, 04:01:55 PM
I have a question about the non standard transactions:

If I leave the default settings (<= 0.00005430 BTC are non standard) and now try to send f.E. 15 BTC and it just happens that this transactions create a change <= 0.00005430 BTC would my client now create a transaction that will not be relayed and included in a block?

Therfore (for an average user) send the 15 BTC into nirvana making them unspendable and unreceivable?

Is there anything included in the new version, that ensures that users don't create non standard transactions by accident without making any user fault?


Title: Re: 0.8.2rc1 ready for testing
Post by: GambitBTC on May 19, 2013, 03:48:31 AM
Looks Great!!


Title: Re: 0.8.2rc1 ready for testing
Post by: TurdHurdur on May 19, 2013, 06:27:56 AM
You idiots know it's just a default setting that can be changed, right?

You can just change this in the config, and connect to a few nodes in pools that accept non-standard tx's.
+1

Knock yourselves out, no fork needed, just add this to your bitcoin.conf and convince a few big miners or mining pools to do the same:

    minrelaytxfee=0



I tried that, but got:

Code:
Error: Invalid amount for -minrelaytxfee=<amount>: '0'

Edit: bug submitted


Title: Re: 0.8.2rc1 ready for testing
Post by: aaaxn on May 19, 2013, 10:10:51 AM
I have a question about the non standard transactions:

If I leave the default settings (<= 0.00005430 BTC are non standard) and now try to send f.E. 15 BTC and it just happens that this transactions create a change <= 0.00005430 BTC would my client now create a transaction that will not be relayed and included in a block?

Therfore (for an average user) send the 15 BTC into nirvana making them unspendable and unreceivable?

Is there anything included in the new version, that ensures that users don't create non standard transactions by accident without making any user fault?
I was going to ask the same question. How software handles situations when legitimate change from big transaction is smaller than minimum output?


Title: Re: 0.8.2rc1 ready for testing
Post by: DeathAndTaxes on May 19, 2013, 10:14:49 AM
Is this version still seeing "merged transactions" as separate transactions for calculating the "minimum fee"...

The prior version was seeing things like this...

Example only... (min fee 0.0005)

{Attempting to send 0.000018506, pulled from many "partial amounts"}
ldfjslkfj 0.000000123 ->
sfoisud 0.000018273 ->
osidufo 0.000000010 ->
doifusid 0.000000100 -> = dkfjsldk [0.000018506] @ fee (0.0005 x 4):[0.00200000] = -0.002018506 total deduction.

Fees get real large, with up to 100 partial "change" mergers into one singular transaction. (Eg, it is treating every change-packet as a separate transaction, though it is simply merging them into ONE singular transaction... thus, expected payment would be 0.0005 not 0.0005x4 = 0.0020...

Fees are (and have always been) PER KB.  If your tx is 4KB then the total fee would be min fee x 4.


Title: Re: 0.8.2rc1 ready for testing
Post by: Maged on May 21, 2013, 06:54:52 PM
I have a question about the non standard transactions:

If I leave the default settings (<= 0.00005430 BTC are non standard) and now try to send f.E. 15 BTC and it just happens that this transactions create a change <= 0.00005430 BTC would my client now create a transaction that will not be relayed and included in a block?

Therfore (for an average user) send the 15 BTC into nirvana making them unspendable and unreceivable?

Is there anything included in the new version, that ensures that users don't create non standard transactions by accident without making any user fault?
I imagine that it works just like it has worked since the 0.3.* series: if a transaction would create a change output below the bitdust levels (which were 0.01), it would add more inputs to the transaction until that no longer the case. If there are no more inputs (like when you're sending most of your bitcoins), that amount is just added to the fee instead of creating change.


Title: Re: 0.8.2rc1 ready for testing
Post by: Pieter Wuille on May 23, 2013, 03:47:29 AM
If I leave the default settings (<= 0.00005430 BTC are non standard) and now try to send f.E. 15 BTC and it just happens that this transactions create a change <= 0.00005430 BTC would my client now create a transaction that will not be relayed and included in a block?

The client will not create such small change.


Title: Re: 0.8.2rc1 ready for testing
Post by: The 4ner on May 24, 2013, 06:18:57 AM
Glad the disappearing GUI problem has been fixed. Great job guys. I'll install when a stable version is released.


Title: Re: 0.8.2rc1 ready for testing
Post by: zvs on May 24, 2013, 06:19:18 AM
Any clue what this person is trying to do (93.92.198.xx)?  The only thing I noticed was that the source port reported in the receive version message was always 18333....  or are these other IPs trying to connect and there's some bug causing it to think it's the 93.92.198.xx address?   Netstat reported 176.9.196.xx, not the 93.92.198.xx on one of them, for example

(ed: oh, lol, it's probably some altcoin junk? ed2: hmm, 18333 port would be related to testnet... these messages started appearing after i pulled the 0.8.2.1)

2013-05-24 05:57:35 accepted connection 5.9.245.xx:59356
2013-05-24 05:57:35 send version message: version 70001, blocks=237642, us=xx.xx.xx.xx:8333, them=5.9.245.xx:59356, peer=5.9.245.xx:59356
2013-05-24 05:57:35 receive version message: version 70001, blocks=80968, us=0.0.0.0:0, them=93.92.198.xx:18333, peer=5.9.245.xx:59356
2013-05-24 05:57:35

PROCESSMESSAGE: INVALID MESSAGESTART

2013-05-24 05:57:35 disconnecting node 5.9.245.xx:59356
2013-05-24 05:57:38 accepted connection 199.193.117.xx:47020
2013-05-24 05:57:38 send version message: version 70001, blocks=237642, us=xx.xx.xx.xx:8333, them=199.193.117.xx:47020, peer=199.193.117.xx:47020
2013-05-24 05:57:38 receive version message: version 70001, blocks=80968, us=0.0.0.0:0, them=93.92.198.xx:18333, peer=199.193.117.xx:47020
2013-05-24 05:57:39

PROCESSMESSAGE: INVALID MESSAGESTART

2013-05-24 05:57:39 disconnecting node 199.193.117.xx:47020
2013-05-24 06:02:33 accepted connection 5.9.0.xx:18244
2013-05-24 06:02:33 send version message: version 70001, blocks=237642, us=xx.xx.xx.xx:8333, them=5.9.0.xx:18244, peer=5.9.0.xx:18244
2013-05-24 06:02:33 receive version message: version 70001, blocks=80968, us=0.0.0.0:0, them=93.92.198.xx:18333, peer=5.9.0.xx:18244
2013-05-24 06:02:33

PROCESSMESSAGE: INVALID MESSAGESTART

2013-05-24 06:02:33 disconnecting node 5.9.0.xx:18244
2013-05-24 06:04:03 accepted connection 176.9.196.xx:12774
2013-05-24 06:04:03 send version message: version 70001, blocks=237642, us=xx.xx.xx.xx:8333, them=176.9.196.xx:12774, peer=176.9.196.xx:12774
2013-05-24 06:04:03 receive version message: version 70001, blocks=80968, us=0.0.0.0:0, them=93.92.198.xx:18333, peer=176.9.196.xx:12774
2013-05-24 06:04:03

PROCESSMESSAGE: INVALID MESSAGESTART

2013-05-24 06:04:03 disconnecting node 176.9.196.xx:12774
2013-05-24 06:09:45 accepted connection 93.92.198.xx:39666
2013-05-24 06:09:45 send version message: version 70001, blocks=237642, us=xx.xx.xx.xx:8333, them=93.92.198.xx:39666, peer=93.92.198.xx:39666
2013-05-24 06:09:45 receive version message: version 70001, blocks=80968, us=0.0.0.0:0, them=93.92.198.xx:18333, peer=93.92.198.xx:39666
2013-05-24 06:09:45

PROCESSMESSAGE: INVALID MESSAGESTART

2013-05-24 06:09:45 disconnecting node 93.92.198.xx:39666


Title: Re: 0.8.2rc1 ready for testing
Post by: The 4ner on May 24, 2013, 06:20:09 AM
* Fix GUI disappearing problem on MacOSX (issue #1522)

Confirm this works, that used to be really annoying, thanks.

It's still not perfect; I have "Minimize windows into application icon" enabled, and if you minimise the window then click on the app dock icon it doesn't un-minimise it whereas other apps do. You need to select Show/Hide from the menu to see it again with Bitcoin-QT. But at least it's not possible to get stuck in a situation where you can't see the UI anymore.

Yeah I hate when this happens. It goes on a lot with the Litecoin client as well.


Title: Re: 0.8.2rc1 ready for testing
Post by: jgarzik on May 24, 2013, 02:33:47 PM
Any clue what this person is trying to do (93.92.198.xx)?  The only thing I noticed was that the source port reported in the receive version message was always 18333....  or are these other IPs trying to connect and there's some bug causing it to think it's the 93.92.198.xx address?   Netstat reported 176.9.196.xx, not the 93.92.198.xx on one of them, for example

(ed: oh, lol, it's probably some altcoin junk? ed2: hmm, 18333 port would be related to testnet... these messages started appearing after i pulled the 0.8.2.1)

2013-05-24 05:57:35 accepted connection 5.9.245.xx:59356
2013-05-24 05:57:35 send version message: version 70001, blocks=237642, us=xx.xx.xx.xx:8333, them=5.9.245.xx:59356, peer=5.9.245.xx:59356
2013-05-24 05:57:35 receive version message: version 70001, blocks=80968, us=0.0.0.0:0, them=93.92.198.xx:18333, peer=5.9.245.xx:59356
2013-05-24 05:57:35

PROCESSMESSAGE: INVALID MESSAGESTART
[...]
2013-05-24 06:09:45 disconnecting node 93.92.198.xx:39666

That seems a reasonable guess.  Either a client program sending garbage, or a client program with a different pchMessageStart (network identifier), connecting on the same port.

A lot of the alt-coins are so lazy, so poorly done that they fail to change the things that bitcoin nodes connect to, like network id or TCP port.



Title: Re: 0.8.2rc1 ready for testing
Post by: Loozik on May 25, 2013, 04:25:30 PM
There is near-universal agreement that the fee system -- its calculation, presentation to users, and other details -- are in need of revision.  That is one of the goals of 0.9, hopefully.

Will this potential revision get rid of older coins having privilege of paying less (or zero) transaction fees?

If you have a dollar bill printed in 2000 and a dollar bill printed in 2010 why would there be a need to discriminate the latter by attaching a higher cost of transacting with it?


Title: Re: 0.8.2rc1 ready for testing
Post by: Akka on May 25, 2013, 05:08:14 PM
There is near-universal agreement that the fee system -- its calculation, presentation to users, and other details -- are in need of revision.  That is one of the goals of 0.9, hopefully.

Will this potential revision get rid of older coins having privilege of paying less (or zero) transaction fees?

If you have a dollar bill printed in 2000 and a dollar bill printed in 2010 why would there be a need to discriminate the latter by attaching a higher cost of transacting with it?

Older coins don't get to pay less. It doesn't matter when you coin was first created. What matters is when your coin was send the last time.

This is only in order to prevent spam (sending the same coin around again and again).

Therefore coins that don't have been moved for a while (1 Bitcoin day) get priority.

That's a fair and useful option IMO. The only ones, that really get a downside from this are the ones that are using high turnover services like Satoshi Dice and it's really fair that these cost a little extra.


Title: Re: 0.8.2rc1 ready for testing
Post by: Loozik on May 25, 2013, 05:54:15 PM
Older coins don't get to pay less. It doesn't matter when you coin was first created. What matters is when your coin was send the last time.

This is only in order to prevent spam (sending the same coin around again and again).

Therefore coins that don't have been moved for a while (1 Bitcoin day) get priority.

That's a fair and useful option IMO. The only ones, that really get a downside from this are the ones that are using high turnover services like Satoshi Dice and it's really fair that these cost a little extra.

Thanks a lot for the explanation. I am less ignorant now  :)


Title: Re: 0.8.2rc1 ready for testing
Post by: gisfrancisco on May 25, 2013, 06:04:35 PM
It won't sync for me.Started it hours ago at 17 hours behind now it's 18.Whats up with that?