Topic: 0.8.2rc1 ready for testing (Read 7711 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?