Bitcoin Forum
December 05, 2016, 02:30:00 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
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 54653 times)
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
February 26, 2012, 05:50:03 PM
 #81

The quickest and easiest solution is probably to change the coin selection algorithm to always select the oldest coin(s) possible for the inputs, thereby not triggering a fee in bitcoind.  In most/many cases that will avoid the fee.

btc_artist:  this is already part of the SelectCoins algorithm optimization  (or at least it is in Armory, I assume Satoshi SelectCoins is similar).  But you don't always win when you do that -- you frequently have no way to construct a transaction without doing something that invokes a fee (usually having to combine lots of tiny inputs to make the transaction).   

From talking to gmaxwell, it sounded like the dust-output trigger (for sending a tx with any sub-0.01 outputs) is universal.  In otherwords, there are plenty of miners that will mine large transactions, or transactions with young inputs, but all nodes impose a fee for dust outputs.  Without it, there's nothing stopping people from spamming the network with single Satoshi coins and adding a GB to the blockchain per day.


Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
1480905000
Hero Member
*
Offline Offline

Posts: 1480905000

View Profile Personal Message (Offline)

Ignore
1480905000
Reply with quote  #2

1480905000
Report to moderator
1480905000
Hero Member
*
Offline Offline

Posts: 1480905000

View Profile Personal Message (Offline)

Ignore
1480905000
Reply with quote  #2

1480905000
Report to moderator
1480905000
Hero Member
*
Offline Offline

Posts: 1480905000

View Profile Personal Message (Offline)

Ignore
1480905000
Reply with quote  #2

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

Activity: 266


View Profile
February 26, 2012, 06:49:32 PM
 #82

I came here looking for a fork you could buy with bitcoins.
It was in the latest post in technical discussion, and I got excited.
And I get this.
Thanks a lot.
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1932



View Profile
February 27, 2012, 12:11:55 AM
 #83

For Sale: Bitcoin Fork
Zwilling J.A. Henckels Premiere Series "Earl Frost" 18/10 Stainless Flatware:
From the makers of the world's finest cutlery since 1731 comes the J. A. Henckels International Flatware Collection. The Earl pattern features a sculpted, contemporary design with a larger, continental size similar to those found in nicer restaurants around the world. All pieces in the collection are made of the highest quality, 18/10 stainless steel. The knives have hollow handles for a better balance and comfortable grip, and finely honed, extra-sharp blades for superior cutting.

Medium Solid Cold Meat Serving Fork:
http://we.lovebitco.in/img/fork1.jpg
http://we.lovebitco.in/img/fork2.jpg
2 BTC, Shipped USA

Complete 5-Piece Hostess Serving Set including fork:
http://ecx.images-amazon.com/images/I/41ASCFDFV4L.jpg
5 BTC Shipped USA
i see what you did there

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
schnell
Sr. Member
****
Offline Offline

Activity: 266


View Profile
February 27, 2012, 07:25:59 AM
 #84

:3
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 27, 2012, 05:16:18 PM
 #85

Could everybody please stop derailing this topic ?

I kind of wanted to use it to inform people about releases of NFTF.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
February 27, 2012, 06:59:26 PM
 #86

https://github.com/bitcoin/bitcoin/pull/570

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 27, 2012, 09:49:33 PM
 #87


Excellent. I will review the code, and if it is what i expect (and it gets pulled into mainline), then i will be able to stop maintaining this fork.

Force strong is with you, Luke - big thanks.


ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 21, 2012, 08:55:30 PM
 #88

2012-03-21 Update:

NFTF - version 0.5.3.1 [critical security vulnerability hotfix] released.

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

More updates (other tags, trunk) should follow soon.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 21, 2012, 09:11:34 PM
 #89

More updates (other tags, trunk) should follow soon.
Be aware that if you cross-compile, 0.6rc4 will only build securely if you rebuild Qt with the gitian hacks first (or merge #946).

Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
March 22, 2012, 01:03:12 AM
 #90

What I would like to see is not only the ability to create transactions without a fee, but also the following:

a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks

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

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1442



View Profile
March 22, 2012, 01:27:05 AM
 #91

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

Steve, that's the best friggin' idea I've read in this forum at least in the last 6 months Wink
And I'm serious!

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 22, 2012, 10:38:30 AM
 #92

What I would like to see is not only the ability to create transactions without a fee, but also the following:

a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks

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

This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.

I have no intention (or required C/C++ skill) of taking it further.

Perhaps somebody else will take up the challenge.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 22, 2012, 02:01:40 PM
 #93

This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.
I'm not aware of any version that didn't force fees...

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 22, 2012, 07:17:37 PM
 #94

This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.
I'm not aware of any version that didn't force fees...

Well yeah - to be precise I am talking about versions that force fee even when there is high probability of it being completely unnecessary.
All versions newer that 0.3.21 do that.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
March 22, 2012, 07:23:55 PM
 #95

b) building on an unconfirmed transaction won't make the original transaction happen any sooner. 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. A Bitcoin modified to allow its users to cancel transmitted transactions (that broke the fee rules anyway) would make a huge double-spend attack vector.

What?

The RECEIVER would build upon the unconfirmed transaction.

i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me).  No fee was included so the transaction isn't being picked up by miners.  I take the unconfirmed B and send it to C (another address owned by me).  I include a fee of 0.10 BTC.

A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block.  A really awesome "confirmation booster".   A solid +1 to Steve.  A very nice way around senders paying for tx fees.

Quote
The solution would be to have a special "add-more-fee" transaction you can send, that can only be added to a block that includes the original transaction. The real solution is to not send payments that clients won't relay and miners won't include.

Um that is exactly what he proposed except there is no need for a special tx.  Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 22, 2012, 07:37:59 PM
 #96

b) building on an unconfirmed transaction won't make the original transaction happen any sooner. 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. A Bitcoin modified to allow its users to cancel transmitted transactions (that broke the fee rules anyway) would make a huge double-spend attack vector.

What?

The RECEIVER would build upon the unconfirmed transaction.

i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me).  No fee was included so the transaction isn't being picked up by miners.  I take the unconfirmed B and send it to C (another address owned by me).  I include a fee of 0.10 BTC.

A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block.  A really awesome "confirmation booster".   A solid +1 to Steve.  A very nice way around senders paying for tx fees.

Quote
The solution would be to have a special "add-more-fee" transaction you can send, that can only be added to a block that includes the original transaction. The real solution is to not send payments that clients won't relay and miners won't include.

Um that is exactly what he proposed except there is no need for a special tx.  Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee.
I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
March 22, 2012, 07:42:45 PM
 #97

True miners would need to notice that B->C depends on A->B but as subsidies decline and tx fees become more important it is a useful way to move the tx cost to the receiver.  Receiver can wait and hope it is included eventually (which maybe the want to do if the payment isn't pressing) or pay a premium fee to get it in the next block. 
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
March 23, 2012, 03:54:29 AM
 #98

I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.
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.  This situation can occur today, though it's probably quite rare given the behavior of the main client.

Regarding my suggestion of a fee that has a high likelihood of making it into the next block, I was thinking of some sort of statistical analysis that could determine a fee that is in the Nth percentile with respect to the time between the transaction appearing on the network and it being included in a block.  You could configure the percentile that you wanted your client to suggest (with perhaps the 95th percentile being the default or so).  This means that if you applied the suggested fee, you would have a transaction that should be in the 95th percentile of all transactions in terms of the time it takes for that transaction to get included in a block.

In most cases, you either want the transaction to get into a block as fast as possible or you don't care at all how long it takes.  So choosing between a 95th percentile fee or no fee at all is likely the only choice most people need.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 23, 2012, 06:50:54 AM
 #99

I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.
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.  This situation can occur today, though it's probably quite rare given the behavior of the main client.

Regarding my suggestion of a fee that has a high likelihood of making it into the next block, I was thinking of some sort of statistical analysis that could determine a fee that is in the Nth percentile with respect to the time between the transaction appearing on the network and it being included in a block.  You could configure the percentile that you wanted your client to suggest (with perhaps the 95th percentile being the default or so).  This means that if you applied the suggested fee, you would have a transaction that should be in the 95th percentile of all transactions in terms of the time it takes for that transaction to get included in a block.

In most cases, you either want the transaction to get into a block as fast as possible or you don't care at all how long it takes.  So choosing between a 95th percentile fee or no fee at all is likely the only choice most people need.

I don't know if you have already figured it out or not, but if you want something done in Free Software world, you have to either do it yourself, or make somebody to do it for you.

This is exactly what i did here, because nobody cared that i do not want to pay fees when they are not necessary.

So the best option is probably to start a fork of your own (if you can code), or pay/convince somebody to do it.

Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
March 23, 2012, 01:09:49 PM
 #100

I don't know if you have already figured it out or not, but if you want something done in Free Software world, you have to either do it yourself, or make somebody to do it for you.

This is exactly what i did here, because nobody cared that i do not want to pay fees when they are not necessary.

So the best option is probably to start a fork of your own (if you can code), or pay/convince somebody to do it.
Yes, I know.  I've worked on open source projects for close to 15 years.  But I also know that if you keep an idea to yourself, there is close to zero chance that someone else will implement it if you don't anticipate having time to do it yourself.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 »  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!