Quote
Why didn't the devs simply make an advanced configuration setting for that is beyond me.
Of course, they try to subtly nudge us to pay miners fee.Good we have folks like youself, who give people choice
Topic: [UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available - page 6. (Read 59296 times)
January 29, 2013, 03:26:55 PM
Hi, could you please change "2012-01-27" Update: to 2013 ?
Good we have folks like youself, who give people choice
Good we have folks like youself, who give people choice
January 27, 2013, 11:38:51 AM
I'm confused by this thread. I thought the fee was always voluntary anyway... ?
Nope, it is not voluntary if the mainline client's algorithm decides so.
This is why i created this fork, because i dislike some decisions of the client. If I want to send money without fee and risk losing it (but the risk is very very low), that should be MY decision, not developer's decision.
Why didn't the devs simply make an advanced configuration setting for that is beyond me.
January 27, 2013, 10:24:02 AM
I'm confused by this thread. I thought the fee was always voluntary anyway... ?
January 27, 2013, 06:58:12 AM
2013-01-27 Update:
NFTF - version 0.7.2 released.
Fresh tag - nftf-v0.7.2 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
MASTER branch was also updated to latest Bitcoin version:
https://github.com/ShadowOfHarbringer/bitcoin-nftf
NFTF - version 0.7.2 released.
Fresh tag - nftf-v0.7.2 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
MASTER branch was also updated to latest Bitcoin version:
https://github.com/ShadowOfHarbringer/bitcoin-nftf
November 04, 2012, 12:11:09 PM
2012-11-04 Update:
NFTF - versions 0.7.0 & 0.7.1 released.
Fresh tags - nftf-v0.7.0, nftf-v0.7.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
----
BTW, since i got bored, here is a picture of grandma roaming the skies on a dolphin (which is kind of not related to the topic, but who cares):
NFTF - versions 0.7.0 & 0.7.1 released.
Fresh tags - nftf-v0.7.0, nftf-v0.7.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
----
BTW, since i got bored, here is a picture of grandma roaming the skies on a dolphin (which is kind of not related to the topic, but who cares):
August 15, 2012, 08:23:24 AM
2012-08-15 Update:
NFTF - version 0.6.3 released.
Fresh tags - nftf-v0.6.3, nftf-v0.6.2.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
Also, I may be making a new repo with Gentoo ebuilds avaiable soon, since I am creating them anyway for my Gentoo.
So stay tuned.
NFTF - version 0.6.3 released.
Fresh tags - nftf-v0.6.3, nftf-v0.6.2.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
Also, I may be making a new repo with Gentoo ebuilds avaiable soon, since I am creating them anyway for my Gentoo.
So stay tuned.
August 08, 2012, 11:47:00 AM
I may have to try it soon, i have tens of thousands of single satoshi inputs, if it works i could make a satoshi dice single satoshi cleaning client that only see's single satoshi inputs and inputs the size of the fee (0.0005 would be good) and sends with whatever minimal fee will work
How did you end up with that?
Quote
The rule nodes apply is MINFEE per KB, so no a single 0.0005 fee wouldn't help you. A single fee works when creating many tiny outputs.
Thats what i thought may happen, some of the transactions before i built a modified client where 90+kb with a ~5 bitcent fee to send less than a bitcent, so i would need to figure out how many inputs to each kilobyte and make transactions accordingly, the client i will make if i end up with too many single satoshi's tied up before there is a way to handle them "built in" could still work with the normal fee calculation, but it would be nice if there we're nodes that followed different rules to maybe pay less... for now the satoshi's can sit in scattered wallets (and hopefully making new wallets is a thing of the past...) if it gets to the point that the dust is worth collecting, there will probably already be a solution
August 08, 2012, 11:22:44 AM
I may have to try it soon, i have tens of thousands of single satoshi inputs, if it works i could make a satoshi dice single satoshi cleaning client that only see's single satoshi inputs and inputs the size of the fee (0.0005 would be good) and sends with whatever minimal fee will work
How did you end up with that?
The rule nodes apply is MINFEE per KB, so no a single 0.0005 fee wouldn't help you. A single fee works when creating many tiny outputs.
August 08, 2012, 09:33:23 AM
If there were a transaction with a lot of single satoshi inputs, and a 0.0005 fee, would it ever confirm?
Haven't tried that yet, you are welcome to be the first
August 08, 2012, 05:20:43 AM
If there were a transaction with a lot of single satoshi inputs, and a 0.0005 fee, would it ever confirm?
Haven't tried that yet, you are welcome to be the first
August 07, 2012, 01:22:44 AM
If there were a transaction with a lot of single satoshi inputs, and a 0.0005 fee, would it ever confirm?
June 20, 2012, 02:43:15 PM
What if there were different tiers of difficulty - if you only include transactions without fees, your difficulty is 'x', if you include transaction fees, it's 'y'. Dedicate one of the 2016 blocks to transactions without fees, so that if someone F's up, they definitely get processed within two weeks. There would be some shifting / weirdness until the difficulty of the 50+fees vs. 50+0 evened out between the two different tactics, but it should eventually police itself such that it's reasonably equally profitable.
June 17, 2012, 05:05:07 PM
b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction
b) ... The method suggested will not work anyway, as the coins in the pending transaction can only be re-sent by the recipient, who is not the sender.
The sender can add fee by re-sending the change.
It wouldn't be a big deal to make transactions always have change. There's usually change anyway.
I think that's a problem that would fix itself if clients had this feature and people started using it. If you're a miner and are actively seeking fee bearing transactions, you really shouldn't be rejecting fee-less transactions if they are inputs to fee bearing transactions that meet your fee requirements.
I agree.
May 26, 2012, 05:46:43 PM
Will do, thanks
May 26, 2012, 04:26:18 PM
Yes it does 
So you will be better off asking about this the core developers (Gavin Andresen etc).
But perhaps it is a common error. Try google first.
May 26, 2012, 01:28:30 PM
Yes it does
May 26, 2012, 11:42:44 AM
Try compiling the mainline version and tell me if it produces the same error.
May 25, 2012, 02:40:04 PM
I just get spammed with errors. Am I missing something?
http://pastebin.com/dpnDMAAj
http://pastebin.com/dpnDMAAj
May 09, 2012, 02:28:38 PM
It is quite safe for everyday usage, if you keep certain rules (eg. not resending money which don't have enough confirmations yet). Sending money which have at least 7 confirmations should be 100% safe, always.
Please do not tell people that it is 100% safe. This is not true and the whole concept of thinking users can tell which money they're resending is wrongheaded, the client has free run to pick from whatever inputs it wants in the wallet. I have helped users unstick their wallets several times as a result of this patch.
I've cautioned you about this in the past— and you responded by pointing out that you were direct about the risks and consequences. Now you violate that by claiming that it's 100% safe.
This is a misunderstanding.
I said:
Quote
Sending money which have at least 7 confirmations should be 100% safe, always
I i wanted to say that I am certain that it is 100% safe, i would say that "IT IS 100% SAFE" or "I AM CERTAIN THAT IT IS 100% SAFE".
If that is not clear enough, i don't know what is.
May 09, 2012, 07:15:34 AM
It is quite safe for everyday usage, if you keep certain rules (eg. not resending money which don't have enough confirmations yet). Sending money which have at least 7 confirmations should be 100% safe, always.
Please do not tell people that it is 100% safe. This is not true and the whole concept of thinking users can tell which money they're resending is wrongheaded, the client has free run to pick from whatever inputs it wants in the wallet. I have helped users unstick their wallets several times as a result of this patch.
I've cautioned you about this in the past— and you responded by pointing out that you were direct about the risks and consequences. Now you violate that by claiming that it's 100% safe.
Yes, it's usually not problematic— after all the overwhelming supermajority of transactions do not need to pay a fee in any case. So yes, in any case where a fee wouldn't have been applied this is safe— but also pointless. In cases where waiting a few hours would have made it no longer need a fee then this is safe enough (at worst you'll need to leave your client running for a few hours before your transaction goes)... but in cases where weeks would be required your funds will end up unusable for a long span of time unless someone helps you effectively hex edit your wallet.
Jump to: