Bitcoin Forum
April 24, 2024, 11:23:18 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 »  All
  Print  
Author Topic: [UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available  (Read 59223 times)
ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
October 02, 2013, 10:43:38 PM
 #181

any update to 0.8.5?
Soon. In progress.

1714000998
Hero Member
*
Offline Offline

Posts: 1714000998

View Profile Personal Message (Offline)

Ignore
1714000998
Reply with quote  #2

1714000998
Report to moderator
1714000998
Hero Member
*
Offline Offline

Posts: 1714000998

View Profile Personal Message (Offline)

Ignore
1714000998
Reply with quote  #2

1714000998
Report to moderator
1714000998
Hero Member
*
Offline Offline

Posts: 1714000998

View Profile Personal Message (Offline)

Ignore
1714000998
Reply with quote  #2

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

Posts: 1714000998

View Profile Personal Message (Offline)

Ignore
1714000998
Reply with quote  #2

1714000998
Report to moderator
1714000998
Hero Member
*
Offline Offline

Posts: 1714000998

View Profile Personal Message (Offline)

Ignore
1714000998
Reply with quote  #2

1714000998
Report to moderator
1714000998
Hero Member
*
Offline Offline

Posts: 1714000998

View Profile Personal Message (Offline)

Ignore
1714000998
Reply with quote  #2

1714000998
Report to moderator
ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
October 07, 2013, 07:38:21 PM
 #182

2013-10-07 Update:

NFTF - versions 0.8.4, 0.8.5 released.

Fresh tag - nftf-v0.8.4, nftf-v0.8.5 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

EDIT: Sorry, mistake. I did not update master this time.

ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
December 22, 2013, 08:23:07 PM
 #183

Ok so I finally successfully built the windows version, but for some reason it is still requiring a fee. I have tried both 5.3.1 and 6.0rc4 and command line version without success. I checked the source I have and it does have your wallet modification. Would there be a reason why it wouldn't let me send fee-less? I am using gitian to build it.
There can be multiple reasons. Like:
- You have received money from a lot of inputs
- The coins do not have enough confirmations

FYI, this fork does not remove fees completely, it only relaxes the fee requirement algorithm. If it does not allow you to send without fee, probably very high risk of losing the coins exists. You can still send them using RAW transactions API, but i wouldn't go for it if I was you.

Also, recheck 3 times if you are using binary built from my code. You may be using other binary.

shark255
Full Member
***
Offline Offline

Activity: 224
Merit: 100



View Profile
December 31, 2013, 09:49:42 AM
 #184

yep! it works for me for 0.01 BTC without fee but takes for 2 hours approx. for confirmation. But good at all. Thanks for developer!
ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
December 31, 2013, 11:26:54 AM
 #185

yep! it works for me for 0.01 BTC without fee but takes for 2 hours approx. for confirmation. But good at all. Thanks for developer!
Yep, it takes longer but it works. That is the exact reason I've built this fork - because i think that the default algo sucks donkey's balls as it requires fee for coins that could be easily sent without.

Abdussamad
Legendary
*
Offline Offline

Activity: 3598
Merit: 1560



View Profile
January 09, 2014, 10:43:28 AM
 #186

If it does not allow you to send without fee, probably very high risk of losing the coins exists.

This worries me. Not because I think there is any chance of loosing coins but because you don't know that there is no chance of loosing coins. Spend transactions are either mined into a block or not. If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee. How exactly is there a risk of "loosing" coins, then?
ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
January 09, 2014, 12:25:12 PM
 #187

If it does not allow you to send without fee, probably very high risk of losing the coins exists.

This worries me. Not because I think there is any chance of loosing coins but because you don't know that there is no chance of loosing coins. Spend transactions are either mined into a block or not. If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee. How exactly is there a risk of "loosing" coins, then?
Ask the core Bitcoin developers. The code which asks you for a fee in that case has not been changed in my fork.

This fork is merely 3 lines of code which turn off a single limitation which forces you to pay a fee even when it is not absolutely necessary. That is not rocket science.

Abdussamad
Legendary
*
Offline Offline

Activity: 3598
Merit: 1560



View Profile
January 09, 2014, 01:42:21 PM
 #188

If it does not allow you to send without fee, probably very high risk of losing the coins exists.

This worries me. Not because I think there is any chance of loosing coins but because you don't know that there is no chance of loosing coins. Spend transactions are either mined into a block or not. If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee. How exactly is there a risk of "loosing" coins, then?
Ask the core Bitcoin developers. The code which asks you for a fee in that case has not been changed in my fork.

This fork is merely 3 lines of code which turn off a single limitation which forces you to pay a fee even when it is not absolutely necessary. That is not rocket science.

You seem to have misunderstood what I wrote. I just said that there is never a risk of loosing your coins just because you didn't pay enough of a fee. You just remove the transaction using pywallet and wait for the mining pools to forget it. Then you can redo the transaction again with a fee.
ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
January 09, 2014, 02:08:18 PM
 #189

If it does not allow you to send without fee, probably very high risk of losing the coins exists.

This worries me. Not because I think there is any chance of loosing coins but because you don't know that there is no chance of loosing coins. Spend transactions are either mined into a block or not. If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee. How exactly is there a risk of "loosing" coins, then?
Ask the core Bitcoin developers. The code which asks you for a fee in that case has not been changed in my fork.

This fork is merely 3 lines of code which turn off a single limitation which forces you to pay a fee even when it is not absolutely necessary. That is not rocket science.

You seem to have misunderstood what I wrote. I just said that there is never a risk of loosing your coins just because you didn't pay enough of a fee. You just remove the transaction using pywallet and wait for the mining pools to forget it. Then you can redo the transaction again with a fee.
This is not what i referred to.
I refrerred to the part of your answer which stated that "it worries you that i don't know that there is no chance of losing coins".

Sure I don't know, because I have not studied the Bitcoin-QT code in detail - I didn't need that in order to create my fork.

If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee
Are you sure about that ? Won't some other nodes keep relaying the transaction so it will be forever stuck in a limbo ?
Is there a time limit for how long a transaction can be kept in memory before it becomes obsolete & is removed ?

[Citation needed] Actually i would like to see a citation (or a snippet of code) for that. I don't have time to study the whole code.

Abdussamad
Legendary
*
Offline Offline

Activity: 3598
Merit: 1560



View Profile
January 09, 2014, 02:23:56 PM
 #190

If it does not allow you to send without fee, probably very high risk of losing the coins exists.

This worries me. Not because I think there is any chance of loosing coins but because you don't know that there is no chance of loosing coins. Spend transactions are either mined into a block or not. If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee. How exactly is there a risk of "loosing" coins, then?
Ask the core Bitcoin developers. The code which asks you for a fee in that case has not been changed in my fork.

This fork is merely 3 lines of code which turn off a single limitation which forces you to pay a fee even when it is not absolutely necessary. That is not rocket science.

You seem to have misunderstood what I wrote. I just said that there is never a risk of loosing your coins just because you didn't pay enough of a fee. You just remove the transaction using pywallet and wait for the mining pools to forget it. Then you can redo the transaction again with a fee.
This is not what i referred to.
I refrerred to the part of your answer which stated that "it worries you that i don't know that there is no chance of losing coins".

Sure I don't know, because I have not studied the Bitcoin-QT code in detail - I didn't need that in order to create my fork.

If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee
Are you sure about that ? Won't some other nodes keep relaying the transaction so it will be forever stuck in a limbo ?
Is there a time limit for how long a transaction can be kept in memory before it becomes obsolete & is removed ?

[Citation needed] Actually i would like to see a citation (or a snippet of code) for that. I don't have time to study the whole code.

I don't have a citation for you. It was asked on this forum and I learned from that. nodes aren't fond of keeping around transactions that can't be mined because the fee is too small. The only reason it sticks around is because -qt keeps broadcasting it over and over again in vain. I can tell you that pywallet supports removing transactions from wallet.dat file for this very reason:

https://bitcointalk.org/index.php?topic=35214.0
ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
January 09, 2014, 03:16:39 PM
 #191

I don't have a citation for you. It was asked on this forum and I learned from that. nodes aren't fond of keeping around transactions that can't be mined because the fee is too small. The only reason it sticks around is because -qt keeps broadcasting it over and over again in vain. I can tell you that pywallet supports removing transactions from wallet.dat file for this very reason:

https://bitcointalk.org/index.php?topic=35214.0
What I am worried about is that the relaying nodes (not mining nodes) will keep broadcasting the transaction forever, and thus - it will be stuck in a limbo.

However you should be able to fix such transaction using Raw Transactions API by rebroadcasting it with a (larger) fee.

Somebody with greater knowledge of Bitcoin-QT code should step in here to clarify that.

deepceleron
Legendary
*
Offline Offline

Activity: 1512
Merit: 1025



View Profile WWW
January 09, 2014, 09:12:48 PM
 #192

Transactions without the minimum fee will not be relayed. They will not be stored in the memory pools of miners. They will not be included in blocks. As they are ignored, a proper fee double-spend transaction will be included promptly.

The minimum fee rules have been simplified in 0.8.6, which is the network majority. A fee is no longer required just because any one output is smaller that 0.01 BTC (dust < 5.6mBTC invalid rule takes care of spam), but the minimum fee is now required for any transaction over 1kB in size. This is in addition to the requirement that input priority less than 57.6M (1 BTC, 144 blocks old; 0.01 BTC ~100 days old) include minimum fee.

The network is currently a hybrid of old rules and new rules, and some Bitcoins may also be altered from defaults by network members.

If users are inclined to throw caution to the wind and try this out, please back up your wallet.dat immediately before transmitting a transaction. It is much easier to restore a wallet backup than to repair your wallet to remove the will-never-confirm spent coin transaction.
ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
January 26, 2014, 03:23:25 PM
Last edit: January 26, 2014, 08:33:01 PM by ShadowOfHarbringer
 #193

Transactions without the minimum fee will not be relayed. They will not be stored in the memory pools of miners. They will not be included in blocks. As they are ignored, a proper fee double-spend transaction will be included promptly.

The minimum fee rules have been simplified in 0.8.6, which is the network majority. A fee is no longer required just because any one output is smaller that 0.01 BTC (dust < 5.6mBTC invalid rule takes care of spam), but the minimum fee is now required for any transaction over 1kB in size. This is in addition to the requirement that input priority less than 57.6M (1 BTC, 144 blocks old; 0.01 BTC ~100 days old) include minimum fee.

The network is currently a hybrid of old rules and new rules, and some Bitcoins may also be altered from defaults by network members.

If users are inclined to throw caution to the wind and try this out, please back up your wallet.dat immediately before transmitting a transaction. It is much easier to restore a wallet backup than to repair your wallet to remove the will-never-confirm spent coin transaction.
Well, it would seem i have to retest my fork for these new conditions.
For now, i will keep updating. When majority is already using new rules, i will check if there is a point in continuing my fork.

ShadowOfHarbringer (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
January 26, 2014, 08:32:46 PM
 #194

2014-01-26 Update:

NFTF - version 0.8.6 released.

Fresh tag - nftf-v0.8.6 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was updated to the last tag (0.8.6).

ISAWHIM
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
January 28, 2014, 04:09:33 AM
 #195

Love your efforts. I stopped using wallets, except for mining, so this is great.

You can't "lose" coins... They either send, or expire.

If your wallet does not see them after they expire, it needs to be "repaired".

However, unless blocks become "full", there should not be any discrimination for "free tx's", ever. That defeats the purpose of the whole network. There is no excuse for discrimination like that. Saying it is for security is like saying you won't allow large transactions, to stop theft. It is not a solution, it is not the purpose of the "transaction processor". Bitcoin is not a business, it is a service. The ones doing the processing should be rejected for blocks, if they fail to "fill a block", when there is ample transactions waiting to fill the block. Free or paid.

If the point comes, at the end of the cycle, when TX-fees MAY be required... Then they should ultimately be enforced. However, difficulty could be zero, so any open wallet could use CPU power for a transaction, and miners would not actually be needed. Why would they do it for free... Because if they want to be able to spend what they earned, they will do it at a cost. Miners are NOT needed for the future of bitcoins and processing.

Fees are already essentially worthless, unless you have a full block full of thousands of $10 fees.

They should have simply made the minimum fee 0.00000001 for all transactions, and then just made bigger blocks as needed. That would have simply solved everything. Well, that and faster block-times.
DannyHamilton
Legendary
*
Offline Offline

Activity: 3374
Merit: 4606



View Profile
January 28, 2014, 02:17:46 PM
 #196

However, unless blocks become "full", there should not be any discrimination for "free tx's", ever. That defeats the purpose of the whole network.

No, it does not.  That is the original intended design of bitcoin whether you want it to be or not. Bitcoin is a voluntary system.  You are not forced to use it, nodes are not forced to relay, miners are not forced to confirm.

There is no excuse for discrimination like that. Saying it is for security is like saying you won't allow large transactions, to stop theft. It is not a solution, it is not the purpose of the "transaction processor".

You have a better suggestion on how to prevent denial of service attack?

Bitcoin is not a business, it is a service.

Mining (transaction processing) IS a business.

The ones doing the processing should be rejected for blocks, if they fail to "fill a block", when there is ample transactions waiting to fill the block. Free or paid.

There is no way to guarantee that the rest of the network knows about every transaction that your node knows about.  There may not have been "ample transactions" at the time that the block was created, but there may be "ample transactions" by the time your node receives the block.  How will your node know how many transactions existed at the time of block creation?  More transactions may come in after the miner starts mining the block, how would you handle such a situation.  Platitudes will get you nowhere. You need to come up with real solutions to real problems, otherwise all your pontificating is just useless noise.

If the point comes, at the end of the cycle, when TX-fees MAY be required... Then they should ultimately be enforced. However, difficulty could be zero, so any open wallet could use CPU power for a transaction, and miners would not actually be needed.

Without a high enough difficulty, blocks will be created too fast, and there will be a rediculous number of orphaned blocks.  Less than a few hundred confirmations will become meaningless since there will be so many forked chains and orphaned blocks.

Why would they do it for free... Because if they want to be able to spend what they earned, they will do it at a cost.

Right, just like everyone will pay transaction fees right now to be able to spend what they earned?  You want others to pay for what you want to use now, why would it be any different in the future?

Miners are NOT needed for the future of bitcoins and processing.

Mining is transaction processing.  If you want transactions processed, then miners (transaction processors) are needed.

Fees are already essentially worthless, unless you have a full block full of thousands of $10 fees.

Block limit is currently 1 MB.  Given average transaction size, I think we can fit about 4,200 transactions per block.  Are you suggesting that fees are worthless unless you have $42,000 in fees per block?  Maximum block size may increase in the future.  If maximum block size is increased to 10 MB, then bitcoin would be able to fit about 42,000 transactions per block.  Are you suggesting that fees are worthless unless you have $420,000 in fees per block?

They should have simply made the minimum fee 0.00000001 for all transactions, and then just made bigger blocks as needed. That would have simply solved everything. Well, that and faster block-times.

I think you are mistaken on that.  Have you even tried the math behind it, or are you just spouting off numbers that you like and assuming that because you like them they must fix all problems?
erikwh
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
February 13, 2014, 06:48:53 AM
 #197

Hi Shadow,

This is an interesting fork and I'm going to read through the thread in more detail.  I have an interest in forwarding small bitcoin amounts between addresses where low fees are more important than timeliness.

If I understand correctly, there are typically currently more transactions spots available per block than are currently being used, so is there any reason that a transaction with the minimum fees will not get incorporated in to the next block?  I'm not sure why there would be any delay if this is the case, and from blockchain.info, all the blocks appear to be under 1M in size.  Any insight here?

Anyways, please correct me if I'm wrong, but I guess I have to find some way to have a huge number of small, old coins in reserve to both keep the minimum priority for each transaction above 57.6 M and each transaction under 1 kB in order to have the network process a transaction with a 0 fee.

Cheers,

Erik
ManaUser
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
April 24, 2014, 04:03:04 AM
 #198

So wait, this is called "No Forced TX Fee" but it still forces TX fees in some cases? Is there any client that REALLY doesn't force transaction fees?
DannyHamilton
Legendary
*
Offline Offline

Activity: 3374
Merit: 4606



View Profile
April 24, 2014, 04:20:16 AM
 #199

So wait, this is called "No Forced TX Fee" but it still forces TX fees in some cases? Is there any client that REALLY doesn't force transaction fees?

As far as I know, this forked client doesn't force you to include a fee.  What makes you think that it does?
ManaUser
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
April 24, 2014, 05:32:24 AM
 #200

As far as I know, this forked client doesn't force you to include a fee.  What makes you think that it does?
This:
FYI, this fork does not remove fees completely, it only relaxes the fee requirement algorithm. If it does not allow you to send without fee, probably very high risk of losing the coins exists. You can still send them using RAW transactions API, but i wouldn't go for it if I was you.
But maybe I'm misunderstanding, the wording is a little bit confusing.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!