Topic: 0.8.2rc1 ready for testing (Read 7744 times)

It won't sync for me.Started it hours ago at 17 hours behind now it's 18.Whats up with that?

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

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.

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?

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.

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

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

Glad the disappearing GUI problem has been fixed. Great job guys. I'll install when a stable version is released.

The client will not create such small change.

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.

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

I was going to ask the same question. How software handles situations when legitimate change from big transaction is smaller than minimum output?

I tried that, but got:


Edit: bug submitted

Looks Great!!

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?

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...

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?

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.

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.

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?

Looks verry Good !!!

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

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.

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.

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.

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?

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!

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.

People thought the same when 0.8 was released.  

EDIT: this comment is not accurate. see below

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.

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.

Initial test results:

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

Works fine on my Win 7 64 bit. And now I have over 63 connected nodes 

Thank you for great work again.

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.

Working great so far, I'm just leaving it running. I guess we will get a release before the 15th?

0.8.2 does not obviously have any high consensus-consistency risk changes.

Is there a risk for a new fork chain ?

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.

Testnet splash screen:


Cool 

Starts up fine under Windows 8 x64.

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.

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*)

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

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

Looks good!

nm, fixed.   

I used newest git and recompiled. "About" says v0.8.0-318-g8c6bbb3-beta. That ok?

Good update, welcome the 0.0001 fee

Confirming the minimization issue.

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.

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://bitcointalksearch.org/topic/reindexing-blocks-on-disk-184125

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."

Nice !

So no changes that might fix reliability of the index then?

The most crucial version ever?  

Hopefully this all goes smoothly!

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.

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.

Keep calm and Test.

Brutal effort on this 0.8.2 release.

Stickied.

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