0.8.2rc1 ready for testing

[BitSlut69]

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?

[1714067129]

1714067129

[1714067129]

1714067129

[1714067129]

1714067129

[1714067129]

1714067129

[DeathAndTaxes]

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.

[gmaxwell]

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.

[keystroke]

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?

[ISAWHIM]

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

[Akka]

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?

[GambitBTC]

Looks Great!!

[TurdHurdur]

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

[aaaxn]

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?

[DeathAndTaxes]

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.

[Maged]

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.

[Pieter Wuille]

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.

[The 4ner]

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

[zvs]

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

[The 4ner]

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

[jgarzik]

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.

[Loozik]

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?

[Akka]

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.

[Loozik]

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 

[gisfrancisco]

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