Bitcoin Forum
December 15, 2017, 06:55:27 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: 0.8.2rc1 ready for testing  (Read 7476 times)
BitSlut69
Jr. Member
*
Offline Offline

Activity: 51


View Profile
May 16, 2013, 05:43:48 PM
 #41


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?
1513320927
Hero Member
*
Offline Offline

Posts: 1513320927

View Profile Personal Message (Offline)

Ignore
1513320927
Reply with quote  #2

1513320927
Report to moderator
1513320927
Hero Member
*
Offline Offline

Posts: 1513320927

View Profile Personal Message (Offline)

Ignore
1513320927
Reply with quote  #2

1513320927
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513320927
Hero Member
*
Offline Offline

Posts: 1513320927

View Profile Personal Message (Offline)

Ignore
1513320927
Reply with quote  #2

1513320927
Report to moderator
1513320927
Hero Member
*
Offline Offline

Posts: 1513320927

View Profile Personal Message (Offline)

Ignore
1513320927
Reply with quote  #2

1513320927
Report to moderator
1513320927
Hero Member
*
Offline Offline

Posts: 1513320927

View Profile Personal Message (Offline)

Ignore
1513320927
Reply with quote  #2

1513320927
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 16, 2013, 05:47:39 PM
 #42


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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2366



View Profile
May 16, 2013, 05:49:04 PM
 #43

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.

Bitcoin will not be compromised
keystroke
Hero Member
*****
Offline Offline

Activity: 842


advocate of a cryptographic attack on the globe


View Profile
May 17, 2013, 02:21:40 PM
 #44

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?

"The difference between a castle and a prison is only a question of who holds the keys."
ISAWHIM
Hero Member
*****
Offline Offline

Activity: 504



View Profile
May 18, 2013, 07:45:58 AM
 #45

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
Legendary
*
Offline Offline

Activity: 1162



View Profile
May 18, 2013, 04:01:55 PM
 #46

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?

All previous versions of currency will no longer be supported as of this update
GambitBTC
Sr. Member
****
Offline Offline

Activity: 476


View Profile
May 19, 2013, 03:48:31 AM
 #47

Looks Great!!
TurdHurdur
Full Member
***
Offline Offline

Activity: 210


View Profile
May 19, 2013, 06:27:56 AM
 #48

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
Full Member
***
Offline Offline

Activity: 238



View Profile WWW
May 19, 2013, 10:10:51 AM
 #49

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 19, 2013, 10:14:49 AM
 #50

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
Legendary
*
Offline Offline

Activity: 1260


View Profile
May 21, 2013, 06:54:52 PM
 #51

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
Legendary
*
qt
Offline Offline

Activity: 1050


View Profile WWW
May 23, 2013, 03:47:29 AM
 #52

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
The 4ner
aka newbitcoinqtuser
Hero Member
*****
Offline Offline

Activity: 546


R.I.P Silk Road 1.0


View Profile
May 24, 2013, 06:18:57 AM
 #53

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

Activity: 1512


I have some bitcoins. Somewhere.


View Profile WWW
May 24, 2013, 06:19:18 AM
 #54

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

Dacentec Dedicated Servers (Lenoir, NC, USA) from $25/mo & Time4VPS Storage VPS' (Vilnius, Lithuania) from €18/qtr & Hetzner's serverbidding, from ~€20/mo -- had bitcoin nodes & p2pool (dacentec, hetzner) for several years on these.  Only two are affiliate links too, kek! -------  Feel free to join my G2A Goldmine Pyramid Scheme Team, or possibly even buy a Steam game from there.  Maybe.
The 4ner
aka newbitcoinqtuser
Hero Member
*****
Offline Offline

Activity: 546


R.I.P Silk Road 1.0


View Profile
May 24, 2013, 06:20:09 AM
 #55

* 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
Legendary
*
qt
Offline Offline

Activity: 1484


View Profile
May 24, 2013, 02:33:47 PM
 #56

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.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Loozik
Sr. Member
****
Offline Offline

Activity: 378


Born to chew bubble gum and kick ass


View Profile
May 25, 2013, 04:25:30 PM
 #57

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
Legendary
*
Offline Offline

Activity: 1162



View Profile
May 25, 2013, 05:08:14 PM
 #58

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.

All previous versions of currency will no longer be supported as of this update
Loozik
Sr. Member
****
Offline Offline

Activity: 378


Born to chew bubble gum and kick ass


View Profile
May 25, 2013, 05:54:15 PM
 #59

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  Smiley
gisfrancisco
Jr. Member
*
Offline Offline

Activity: 52


View Profile
May 25, 2013, 06:04:35 PM
 #60

It won't sync for me.Started it hours ago at 17 hours behind now it's 18.Whats up with that?
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!