Peter Todd
Legendary
Offline
Activity: 1120
Merit: 1152
|
|
March 23, 2013, 08:58:03 AM |
|
Read the code, not some wiki.
Priority is only used if the minimum fee is zero. If there is a dust output, the minimum fee calculated by GetMinFee() is not zero.
|
|
|
|
gweedo
Legendary
Offline
Activity: 1498
Merit: 1000
|
|
March 23, 2013, 09:03:39 AM |
|
Read the code, not some wiki.
Priority is only used if the minimum fee is zero. If there is a dust output, the minimum fee calculated by GetMinFee() is not zero.
You have no link to the code, I can't take your word for a snippet, but I am still 99.999999% sure that dust, that is aged can be sent without a fee, if aged. I coded a faucet, I kinda know what I am talking about in that sense, and the wiki is also pretty reliable.
|
|
|
|
Peter Todd
Legendary
Offline
Activity: 1120
Merit: 1152
|
|
March 23, 2013, 09:07:18 AM |
|
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
March 23, 2013, 09:10:27 AM |
|
Didn't know you could add the line # to such source links - nice! But just below that is the following: if (fAllowFree) { if (nBlockSize == 1) { // Transactions under 10K are free // (about 4500 BTC if made of 50 BTC inputs) if (nBytes < 10000) nMinFee = 0; } else { // Free transaction area if (nNewBlockSize < 27000) nMinFee = 0; } }
And the call you showed to this function sets fAllowFree to true.
|
|
|
|
Peter Todd
Legendary
Offline
Activity: 1120
Merit: 1152
|
|
March 23, 2013, 09:15:41 AM |
|
The code you quoted sets nMinFee to zero if there is space left in the current block, or if the size is less than 10KB, depending on the value of the nBlockSize argument to the function.
However regardless of what nMinFee is set to the next part sets nMinFee to nBaseFee - either 0.0005 or 0.0001 depending on if the fee is being calculated for transaction relay or inclusion in a block - regardless of fAllowFree if there is a dust output.
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
March 23, 2013, 09:21:05 AM |
|
Interesting - does this apply to both "sides" of the tx (i.e. the input UTXOs and the output UTXOs)?
|
|
|
|
Peter Todd
Legendary
Offline
Activity: 1120
Merit: 1152
|
|
March 23, 2013, 09:23:54 AM |
|
Interesting - does this apply to both "sides" of the tx (i.e. the input UTXOs and the output UTXOs)?
No, only outputs.
|
|
|
|
|
BitHits (OP)
|
|
March 23, 2013, 09:51:48 PM |
|
wait...so you mean to tell me the age of my coins is the primary factor? I thought it was the size of the transaction that was the main driver... I'm assuming when sending coins using Official Client its automatically using the oldest coins first... priority = sum(input_value_in_base_units * input_age)/size_in_bytes so the total value of the transaction * the age / size of tx.... you would think a larger transaction....would have a smaller fee then and if that formula is taken literally, the OLDER the coins, the higher the fee.... Assuming a tx value of 0.04 and an age of 1 day and 4 days, with a 20,000 byte size $calc(0.04 * 1)/20000) = 0.04 fee to send 0.04 $calc(0.04 * 4)/20000) = 0.16 fee to send 0.04 at the same time, thats not the fee thats calculated Thats the priority, so a lower priority would incur a larger fee and a higher priority would incur a lower fee.... so really 0.04 priority on 1 day old coins and 0.16 priority on 4 day old coins. So....those calculations are not exact or accurate at all, but proportionately they should be close. As I'm sure the number formats I'm using are not the same passed in the protocol or used in actual calculation... Using the real values, what would be the ideal age/size for a transaction of 0.0208 lets say to 2600 Addresses for a size of about... 100kb (0.000008 to each addr)
|
Free BTC http://beta.BitHits.info BTC 1DNNERMT5MMusfYnCBfcKCBjBKZWBC5Lg2 DGC DH2Pm4VXxsTeqUYZkEySU1c8p5TLvuLe8u LTC LP2QiL1pnsaKVX5Qa811pFJuFL8FxkxWRz
|
|
|
BitHits (OP)
|
|
March 23, 2013, 10:10:03 PM |
|
40686 size 0.94498248 input fees came out to 0.0205 1191 addresses paid... majority of that transaction was to 1CQxknB3zDS6tCLJUP7ZBfTS8yfRmABjhT 0.94497058 BTC I've thought about included a larger input to an affiliate or something usually like 400uBTC if i process a 4 day payout, could try to process like 14 days at a time, but would have to be broken up into many transactions Also the larger input was probably added later by the network, ive seen that happen on some of my payout transactions.
|
Free BTC http://beta.BitHits.info BTC 1DNNERMT5MMusfYnCBfcKCBjBKZWBC5Lg2 DGC DH2Pm4VXxsTeqUYZkEySU1c8p5TLvuLe8u LTC LP2QiL1pnsaKVX5Qa811pFJuFL8FxkxWRz
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
|
March 23, 2013, 10:31:38 PM |
|
Straight Bitcoin isn't designed for really small transactions. If you're sending less than something like $1 worth of bitcoins, you should expect to pay 10% or more in fees. More if you're trying to send $0.10 or less.
There is no magic fairy wand we can wave and make Bitcoin suddenly great for gazillions of tiny transactions; plan your businesses accordingly. As transaction volume increases, there will be more competition for space in blocks and fees are likely to rise.
And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
BitHits (OP)
|
|
March 23, 2013, 10:38:13 PM |
|
Straight Bitcoin isn't designed for really small transactions. If you're sending less than something like $1 worth of bitcoins, you should expect to pay 10% or more in fees. More if you're trying to send $0.10 or less.
There is no magic fairy wand we can wave and make Bitcoin suddenly great for gazillions of tiny transactions; plan your businesses accordingly. As transaction volume increases, there will be more competition for space in blocks and fees are likely to rise.
And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").
Wow! For someone to get $1 worth of bitcoins...at current rate....using many of the Faucet sites.... They'd have to max out their limit on my site for 25 days straight...That would also mean I would need to process a months worth of transactions at a time..... And your doing this...by design!? Also adding an option to voluntarily declare your output non-standard and pay no tx fee or a fee with a reasonable calculation based on tx input would be a great option! I'm paying 1000% in fees currently. So fuck 10% would be awesome!
|
Free BTC http://beta.BitHits.info BTC 1DNNERMT5MMusfYnCBfcKCBjBKZWBC5Lg2 DGC DH2Pm4VXxsTeqUYZkEySU1c8p5TLvuLe8u LTC LP2QiL1pnsaKVX5Qa811pFJuFL8FxkxWRz
|
|
|
jaywaka2713
Sr. Member
Offline
Activity: 266
Merit: 250
aka 7Strykes
|
|
March 23, 2013, 10:40:13 PM |
|
Actually, I'm trying to run a BitCoin Faucet/PTC Site. www.BitHits.infoThe fees are becoming ridiculous thou! Try only paying out once a day by grouping every transaction together.
|
|
|
|
BitHits (OP)
|
|
March 23, 2013, 10:48:37 PM Last edit: March 23, 2013, 11:07:55 PM by BitHits |
|
|
Free BTC http://beta.BitHits.info BTC 1DNNERMT5MMusfYnCBfcKCBjBKZWBC5Lg2 DGC DH2Pm4VXxsTeqUYZkEySU1c8p5TLvuLe8u LTC LP2QiL1pnsaKVX5Qa811pFJuFL8FxkxWRz
|
|
|
jaywaka2713
Sr. Member
Offline
Activity: 266
Merit: 250
aka 7Strykes
|
|
March 23, 2013, 11:01:38 PM |
|
Some send once a week. Try asking other faucet admins about their methods and see if you can pick up a script to automate sendmany for you. I'm sure their servers contain such scripts. If anything, try looking at the source code of a faucet site and see if the input area for the Bitcoin Address sends the input to a script, and if so, rip the script and reverse it for your server. I'm sure asking for it would be much easier though.
|
|
|
|
BitHits (OP)
|
|
March 23, 2013, 11:09:18 PM |
|
I've been in touch with the admins of two other sites.
So far I've been suggested to use the mtgox api
|
Free BTC http://beta.BitHits.info BTC 1DNNERMT5MMusfYnCBfcKCBjBKZWBC5Lg2 DGC DH2Pm4VXxsTeqUYZkEySU1c8p5TLvuLe8u LTC LP2QiL1pnsaKVX5Qa811pFJuFL8FxkxWRz
|
|
|
jaywaka2713
Sr. Member
Offline
Activity: 266
Merit: 250
aka 7Strykes
|
|
March 25, 2013, 03:13:24 AM |
|
I've been in touch with the admins of two other sites.
So far I've been suggested to use the mtgox api
That actually would be much better than just writing a simple script, as such a script could potentially kill a server that doesn't have enough RAM. Try generating a payment request of 2000+ addresses with variable payments and such in one command. Potential lag fest. MtGox API would be much cleaner.
|
|
|
|
Dabs
Legendary
Offline
Activity: 3416
Merit: 1912
The Concierge of Crypto
|
|
March 25, 2013, 06:26:56 AM |
|
Straight Bitcoin isn't designed for really small transactions. If you're sending less than something like $1 worth of bitcoins, you should expect to pay 10% or more in fees. More if you're trying to send $0.10 or less.
There is no magic fairy wand we can wave and make Bitcoin suddenly great for gazillions of tiny transactions; plan your businesses accordingly. As transaction volume increases, there will be more competition for space in blocks and fees are likely to rise.
And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").
Hi. How is "dust" defined? Does that mean, the real smallest bitcoin unit is not really a Satoshi or 0.00000001? What good are the 8 decimal places for when you can't really use them? That just cuts down on the value or divisibility of the coin. Also, for a Satoshi, how long must it be aged before you can spend it without a fee? I've got some dust from an older wallet that I can't get right now, so either I wait for it to age, or I figure out a way to send it to myself without a fee. What's one work around for this? Can I use larger amounts together with my dust so I can consolidate them without a fee?
|
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1036
|
|
March 25, 2013, 04:40:05 PM |
|
This is blockchain spam. You are sending thousands of 0.000002-0.000006 BTC payments that can hardly be spent (the recipient has to pay minimum fees to spend them too). If Bitcoins were $1000 each these are still fractions of a USD penny. I would be pissed if you sent this crap to my wallet. Only the naive would sign up or expend any effort to receive such payments. One transaction - 1/10th of a megabyte that has to be stored by every node on the network forever and transmitted to every new user before they can use Bitcoin, you really think that 0.049 BTC is too expensive to do that? Ask Western Union how much they would charge to send 1000 money transfers that can be redeemed anywhere in the world.
|
|
|
|
nonnakip
|
|
March 30, 2013, 10:30:55 PM |
|
And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").
By default nothing should be censored. Miners and relay nodes must decide for themselves if they want to censor by actively enabling a censor. Do not use a censor as a solution to your failed technical implementation.
|
|
|
|
|