.

[phelix]

... and fixed so you can specify transactions, not just addresses.

Coin Control is included in today's next-test release. Please give it a try!

As has been mentioned before and I mentioned in here recently (but got ignored), just going to address level is insufficient.
Selecting the source for a txn should be to transaction level.

is it not possible to achieve the same with coin control and a separate address for every transaction?

?

So for the average joe's wallet that might want to use this to choose transactions or addresses, it's no good since you have to have done this from the start and always remember to do it that way?

My point being that your saying that this is only of use to people who have anonymity issues, rather than also for those who wish to have control over certain transactions
i.e. going one more level is as far as is possible with selecting sources for a transaction - and why not allow that? Why stop early?

maybe not stop but take one step after the other.

[1713563395]

1713563395

[1713563395]

1713563395

[1713563395]

1713563395

[1713563395]

1713563395

[kano]

As has been mentioned before and I mentioned in here recently (but got ignored), just going to address level is insufficient.
Selecting the source for a txn should be to transaction level.

See the raw transaction API I've been working on, and please help try to break it-- it needs more testing.

The main motivation is to move forward with multisignature transactions, but it also lets you have complete control over the source(s) for a transaction.

Yep sounds good - with that in there, tools like this will become simpler code calling your API.

However, as mentioned above, the issue of fees is still outstanding - which does relate VERY closely to this.

If you are selecting addresses or transactions to make up a transaction, you need to know the fees involved also.
What I was referring to further up was to simply have a 2 phase call to this process.
Phase 1 tells you the fee for your txn
Then phase 2 you send a modified txn with fee and it says yes it works, or replies with a new fee if it changed.
... well something like that anyway.
(not a 2 phase commit in database terms, but a 2 step commit)

[Gavin Andresen]

However, as mentioned above, the issue of fees is still outstanding - which does relate VERY closely to this.

Determining the "right" fees is a separate issue; see https://gist.github.com/2961409  for my current thinking.

The raw transaction API will let you create and try to send a transaction with as much or little fees as you like, but if you try to send a 20 kilobyte transaction with zero fees you shouldn't be surprised if nobody relays or mines it.

This looks interesting - just one question after reading this document (as the word "change" does not appear in it at all) - will it be also possible to specify the *change* address with such "raw transactions" (in perhaps the sendrawtx command itself)?

If you use the raw transaction API then you're responsible for saying exactly where all of the outputs go.  If you create a raw transaction with a 50 BTC input and a 2 BTC output then that is a no-change, 48 BTC fee transaction.  If you don't intend the 48 BTC to go to miners, then you need to specify where the change goes by adding another output.

I suppose the RPC calls could have limits to try to keep you from shooting yourself in the foot, but anybody using the raw transaction API should be doing a lot of testing with worthless testnet coins and I'd rather not start playing the "lets write lots of code to try to prevent RPC-users from being dumb" game.

[49er]

This interests me.  Not the anonymity aspect, but the fine grain control per address.  I prefer this to opening and closing multiple wallets, which feels like a clumsy approach.

[Luke-Jr]

This interests me.  Not the anonymity aspect, but the fine grain control per address.  I prefer this to opening and closing multiple wallets, which feels like a clumsy approach.

I this the current multi-wallet plan allows for having multiple open concurrently.

[CIYAM]

If you use the raw transaction API then you're responsible for saying exactly where all of the outputs go.  If you create a raw transaction with a 50 BTC input and a 2 BTC output then that is a no-change, 48 BTC fee transaction.  If you don't intend the 48 BTC to go to miners, then you need to specify where the change goes by adding another output.

Okay - thanks - I get it now - and yes I think that this will be of great benefit for the development of other clients that sit above bitcoind (or just for "power" users of the RPC interface).

[49er]

This interests me.  Not the anonymity aspect, but the fine grain control per address.  I prefer this to opening and closing multiple wallets, which feels like a clumsy approach.

I this the current multi-wallet plan allows for having multiple open concurrently.

You that? 

While I'm sure there are special use cases where it's the better option, I still feel multiple wallets is overkill when one will do for most people.  I also can't help but think the multiple "accounts" per wallet introduced in 0.3.18 should have covered most of the multiple wallet use cases.  I would have expected this in the GUI before the more heavyweight multi-wallet changes.

[ShadowOfHarbringer]

* ShadowOfHarbringer is watching this.

[EnergyVampire]

Interesting...

[gmaxwell]

I never understood why the fee calculation has to bee so complicated...  age of coins - wtf why?

The question:

How can we have free transactions, but not make it possible for someone to cheaply DOS the system into oblivion by simply typing "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.00000001 ; done" ?

To solve this we ask:  What characterizes that kind of activity which is distinct from normal usage?    We can't tell that the DOS transactions are all coming from a single party because they can just use many addresses.  We can't really single out smallish transactions because regular users make small transactions and the attack would work just as well even it was moving 50 BTC in each transaction. What characterizes them is that they're rapidly moving the same coins over and over again.

Bitcoin days destroyed is a simple metric that measures coin velocity, and it's basically what the prioritiy system uses.  Sum(input_values * input_ages) / tx_data_size = priority.

Our priority system in effect uses the transaction's Bitcoin days destroyed to pay for them— evidence that the user isn't engaging in a maximum speed coin recycling— in lieu of fees.  The metric is directly connected to real DOS attack behavior, it doesn't depend on the impossible task of distinguishing users, it doesn't disproportionally penalize low value transactions, it expends a real scarce resource (though not one that users consider otherwise valuable), it doesn't actively encourage bad behavior, and it's demonstratively effective. If you don't have enough priority or pay a fee peer nodes will not relay your transaction, miners will not mine it— not until it does have enough priority via aging.

With this metric an attacker is required to have an enormous and near unending supply of unmoved coin in order to sustain an attack or they must spend on fees (or con some suckers into paying fees for them).

The downsides are that it can be a bit inexplicable for the users— "you can't make a free txn now, but you can after the next block??", which is made worse by the fact that the reference software doesn't really try to construct transactions in a way that avoids fees— and more complicated to find _optimal_ coin selections with this metric (it makes the objective non-linear). But otherwise it's a pretty excellent metric.

[Ente]

I never understood why the fee calculation has to bee so complicated...  age of coins - wtf why?

The question:

How can we have free transactions, but not make it possible for someone to cheaply DOS the system into oblivion by simply typing "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.00000001 ; done" ?

To solve this we ask:  What characterizes that kind of activity which is distinct from normal usage?    We can't tell that the DOS transactions are all coming from a single party because they can just use many addresses.  We can't really single out smallish transactions because regular users make small transactions and the attack would work just as well even it was moving 50 BTC in each transaction. What characterizes them is that they're rapidly moving the same coins over and over again.

Bitcoin days destroyed is a simple metric that measures coin velocity, and it's basically what the prioritiy system uses.  Sum(input_values * input_ages) / tx_data_size = priority.

Our priority system in effect uses the transaction's Bitcoin days destroyed to pay for them— evidence that the user isn't engaging in a maximum speed coin recycling— in lieu of fees.  The metric is directly connected to real DOS attack behavior, it doesn't depend on the impossible task of distinguishing users, it doesn't disproportionally penalize low value transactions, it expends a real scarce resource (though not one that users consider otherwise valuable), it doesn't actively encourage bad behavior, and it's demonstratively effective. If you don't have enough priority or pay a fee peer nodes will not relay your transaction, miners will not mine it— not until it does have enough priority via aging.

With this metric an attacker is required to have an enormous and near unending supply of unmoved coin in order to sustain an attack or they must spend on fees (or con some suckers into paying fees for them).

The downsides are that it can be a bit inexplicable for the users— "you can't make a free txn now, but you can after the next block??", which is made worse by the fact that the reference software doesn't really try to construct transactions in a way that avoids fees— and more complicated to find _optimal_ coin selections with this metric (it makes the objective non-linear). But otherwise it's a pretty excellent metric.

Your question answered many of my questions regarding transactions, forwarding, fees and DOS.
Thank you.

Ente

[Red Emerald]

I never understood why the fee calculation has to bee so complicated...  age of coins - wtf why?

The question:

How can we have free transactions, but not make it possible for someone to cheaply DOS the system into oblivion by simply typing "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.00000001 ; done" ?

To solve this we ask:  What characterizes that kind of activity which is distinct from normal usage?    We can't tell that the DOS transactions are all coming from a single party because they can just use many addresses.  We can't really single out smallish transactions because regular users make small transactions and the attack would work just as well even it was moving 50 BTC in each transaction. What characterizes them is that they're rapidly moving the same coins over and over again.

Bitcoin days destroyed is a simple metric that measures coin velocity, and it's basically what the prioritiy system uses.  Sum(input_values * input_ages) / tx_data_size = priority.

Our priority system in effect uses the transaction's Bitcoin days destroyed to pay for them— evidence that the user isn't engaging in a maximum speed coin recycling— in lieu of fees.  The metric is directly connected to real DOS attack behavior, it doesn't depend on the impossible task of distinguishing users, it doesn't disproportionally penalize low value transactions, it expends a real scarce resource (though not one that users consider otherwise valuable), it doesn't actively encourage bad behavior, and it's demonstratively effective. If you don't have enough priority or pay a fee peer nodes will not relay your transaction, miners will not mine it— not until it does have enough priority via aging.

With this metric an attacker is required to have an enormous and near unending supply of unmoved coin in order to sustain an attack or they must spend on fees (or con some suckers into paying fees for them).

The downsides are that it can be a bit inexplicable for the users— "you can't make a free txn now, but you can after the next block??", which is made worse by the fact that the reference software doesn't really try to construct transactions in a way that avoids fees— and more complicated to find _optimal_ coin selections with this metric (it makes the objective non-linear). But otherwise it's a pretty excellent metric.

Your question answered many of my questions regarding transactions, forwarding, fees and DOS.
Thank you.

Ente

This is a great explanation. I'm going to put this on the wiki.

EDIT: Or not. I've forgotten my wiki password. I guess I'll do it later

[phelix]

I never understood why the fee calculation has to bee so complicated...  age of coins - wtf why?

The question:

How can we have free transactions, but not make it possible for someone to cheaply DOS the system into oblivion by simply typing "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.00000001 ; done" ?

To solve this we ask:  What characterizes that kind of activity which is distinct from normal usage?    We can't tell that the DOS transactions are all coming from a single party because they can just use many addresses.  We can't really single out smallish transactions because regular users make small transactions and the attack would work just as well even it was moving 50 BTC in each transaction. What characterizes them is that they're rapidly moving the same coins over and over again.

Bitcoin days destroyed is a simple metric that measures coin velocity, and it's basically what the prioritiy system uses.  Sum(input_values * input_ages) / tx_data_size = priority.

Our priority system in effect uses the transaction's Bitcoin days destroyed to pay for them— evidence that the user isn't engaging in a maximum speed coin recycling— in lieu of fees.  The metric is directly connected to real DOS attack behavior, it doesn't depend on the impossible task of distinguishing users, it doesn't disproportionally penalize low value transactions, it expends a real scarce resource (though not one that users consider otherwise valuable), it doesn't actively encourage bad behavior, and it's demonstratively effective. If you don't have enough priority or pay a fee peer nodes will not relay your transaction, miners will not mine it— not until it does have enough priority via aging.

With this metric an attacker is required to have an enormous and near unending supply of unmoved coin in order to sustain an attack or they must spend on fees (or con some suckers into paying fees for them).

The downsides are that it can be a bit inexplicable for the users— "you can't make a free txn now, but you can after the next block??", which is made worse by the fact that the reference software doesn't really try to construct transactions in a way that avoids fees— and more complicated to find _optimal_ coin selections with this metric (it makes the objective non-linear). But otherwise it's a pretty excellent metric.

Your question answered many of my questions regarding transactions, forwarding, fees and DOS.
Thank you.

Ente

This is a great explanation. I'm going to put this on the wiki.

EDIT: Or not. I've forgotten my wiki password. I guess I'll do it later

thanks for the nice explanation and +1 to putting it into the wiki.

still this seems overengineered to me. what does somebody moving a large pile of coins once a year care about a 0.01btc fee? also it complicates emptying of addresses and I imagine the decision of pools to delay/not include free txs.

[zebedee]

I don't think anyone has said it yet, so I'll just point out that this feature is available in the electrum client - you can prioritize addresses that you received at for a payment.  In particular, if you prioritize an address that received more than you're sending, you can be sure that only that address is used for the payment.

[N.Z.]

Strange things are happening to this useful patch. Author and followers abandon support for it constantly. More than a year has passed, but there is nothing about it in official client, even "experimental" and "for advanced use only". WTF...

P.S. Just my 0.02 btc, nevermind

[ShadowOfHarbringer]

Strange things are happening to this useful patch. Author and followers abandon support for it constantly. More than a year has passed, but there is nothing about it in official client, even "experimental" and "for advanced use only". WTF...

P.S. Just my 0.02 btc, nevermind

Actually i remember reading somewhere that this will be implemented in 0.7.
Am I wrong ?

[Luke-Jr]

Strange things are happening to this useful patch. Author and followers abandon support for it constantly. More than a year has passed, but there is nothing about it in official client, even "experimental" and "for advanced use only". WTF...

P.S. Just my 0.02 btc, nevermind

Actually i remember reading somewhere that this will be implemented in 0.7.
Am I wrong ?

No, since the author and subsequent maintainer have both abandoned it, there is nobody to address the problems still left unresolved. Until that happens, it will not likely be merged. For the time being, I am keeping it minimally up to date for my next-test branches.

[ShadowOfHarbringer]

Strange things are happening to this useful patch. Author and followers abandon support for it constantly. More than a year has passed, but there is nothing about it in official client, even "experimental" and "for advanced use only". WTF...

P.S. Just my 0.02 btc, nevermind

Actually i remember reading somewhere that this will be implemented in 0.7.
Am I wrong ?

No (...)

BTW, You just did a double-negative answer which could be understood by me as "yes you are right"

(Just fooling around here, don't mind me)

[phelix]

I don't think anyone has said it yet, so I'll just point out that this feature is available in the electrum client - you can prioritize addresses that you received at for a payment.  In particular, if you prioritize an address that received more than you're sending, you can be sure that only that address is used for the payment.

interesting...

[phelix]

Strange things are happening to this useful patch. Author and followers abandon support for it constantly. More than a year has passed, but there is nothing about it in official client, even "experimental" and "for advanced use only". WTF...

P.S. Just my 0.02 btc, nevermind

Actually i remember reading somewhere that this will be implemented in 0.7.
Am I wrong ?

No, since the author and subsequent maintainer have both abandoned it, there is nobody to address the problems still left unresolved. Until that happens, it will not likely be merged. For the time being, I am keeping it minimally up to date for my next-test branches.

like here: https://bitcointalk.org/index.php?topic=100390.0

thanks luke!