Yet another Coin Control Release [CLOSED] - page 3.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: 0x00ff on December 03, 2013, 10:10:55 AM

I think in sense of acceptance the CoinControl stuff should get into the 'official' release ASAP.

It is already merged into what will become 0.9.

Quote from: 0x00ff on December 03, 2013, 10:10:55 AM

One question is still open for me, however: the CC stuff uses the 100 addesses generated when the wallet was created, right? Will it - when the 100 addresses for change are used - generate 100 new ones or one-by-one with any transaction? So, I unsure about the backup strategy for the wallet...

Bitcoin-Qt will create a new address every transaction, to ensure you always have 100 unused.
So I recommend backing up every 90 transactions.
Note this is entirely unrelated to coincontrol...

0x00ff

newbie

Activity: 56

Merit: 0

I just tried out CoinControl build from the OP. The thing that I noticed was that it downloaded? and checked the whole chain again. This tool very long. But the GUI now makes sense to anyone, what Bitcoin-QT did not. 20 BTC in there, 1 spent, 0 remaining.

I think in sense of acceptance the CoinControl stuff should get into the 'official' release ASAP.

One question is still open for me, however: the CC stuff uses the 100 addesses generated when the wallet was created, right? Will it - when the 100 addresses for change are used - generate 100 new ones or one-by-one with any transaction? So, I unsure about the backup strategy for the wallet...

loquitus_of_borg

newbie

Activity: 50

Merit: 0

Frankly it seems to work as advertised. That's why I am puzzled why it is being called a bug.

Bugs are supposed to be behaviour that do not reflect what is expected behaviour.

Quote from: CIYAM on November 28, 2013, 11:44:11 PM

Quote from: binaryFate on November 28, 2013, 09:35:20 PM

Call it a feature that you find useless then. That's all but the definition of a bug.

I would have to agree that Luke-Jr seems to be a bit confused about what a "bug" is.

Perhaps he is just getting a bit overzealous about his dislike of this "feature". Wink

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

Quote from: binaryFate on November 28, 2013, 09:35:20 PM

Call it a feature that you find useless then. That's all but the definition of a bug.

I would have to agree that Luke-Jr seems to be a bit confused about what a "bug" is.

Perhaps he is just getting a bit overzealous about his dislike of this "feature". Wink

binaryFate

legendary

Activity: 1484

Merit: 1003

Still wild and free

Quote from: Luke-Jr on November 27, 2013, 07:08:28 PM

Quote from: loquitus_of_borg on November 27, 2013, 07:05:59 PM

Quote from: Luke-Jr on November 27, 2013, 06:44:36 PM

Quote from: loquitus_of_borg on November 27, 2013, 05:58:35 PM

On another note, electrum has a payto command (and a paytomany) that allows you to specify the from address. I am assuming this is essentially doing what I am talking about here, right?

This is a bug. There is no from address.

electrum help payto
Create and broadcast a transaction.
Syntax: payto [label]
can be a bitcoin address or a label
options:
--fee, -f: set transaction fee
--fromaddr, -F: send from address -
--changeaddr, -c: send change to address

Are you saying that the "feature" where I specify the fromaddr above is misnamed, or something else? I assumed that by specifying the from addr, it simply would only use unspent transaction outputs that were going to that specified address, as the inputs for the new outgoing transaction.

Is this incorrect?

It's not a feature, it's a bug. There is no use case for selecting UTXO entries based on the transaction they were created by.

Call it a feature that you find useless then. That's all but the definition of a bug.

Cryddit

legendary

Activity: 924

Merit: 1129

Doesn't look like a bug to me.

Using all of (and ONLY) what's at one address in each transaction is by far the best way to prevent people from being able to infer that UTXO 1 and UTXO 2 are held by the same wallet (which is you). Meaning they can't link you to other transactions besides those that created UTXOs having that address. Which were already linked, if you dealt with someone who was such an idiot as to pay more than once to the same address.

So, yes, I have a use case for "micromanagement" of the from addresses. It's called privacy. Coin control ought to have a setting that lets me make it automatic, or at least warns me if I can't make a transaction that follows that rule and lets me *PICK* which UTXOs I don't mind someone linking.

loquitus_of_borg

newbie

Activity: 50

Merit: 0

Hmm.

So what does this in fact do? I realize you said it is a bug. From how I saw it when I used it, I specified the "from" address to source funds from, and the resulting new transaction showed that unspent outputs to that from address ALONE were used to source the new transaction. Maybe I am just missing something fundamental here.

Quote from: Luke-Jr on November 27, 2013, 07:08:28 PM

Quote from: loquitus_of_borg on November 27, 2013, 07:05:59 PM

Quote from: Luke-Jr on November 27, 2013, 06:44:36 PM

Quote from: loquitus_of_borg on November 27, 2013, 05:58:35 PM

On another note, electrum has a payto command (and a paytomany) that allows you to specify the from address. I am assuming this is essentially doing what I am talking about here, right?

This is a bug. There is no from address.

electrum help payto
Create and broadcast a transaction.
Syntax: payto [label]
can be a bitcoin address or a label
options:
--fee, -f: set transaction fee
--fromaddr, -F: send from address -
--changeaddr, -c: send change to address

Are you saying that the "feature" where I specify the fromaddr above is misnamed, or something else? I assumed that by specifying the from addr, it simply would only use unspent transaction outputs that were going to that specified address, as the inputs for the new outgoing transaction.

Is this incorrect?

It's not a feature, it's a bug. There is no use case for selecting UTXO entries based on the transaction they were created by.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: loquitus_of_borg on November 27, 2013, 07:05:59 PM

Quote from: Luke-Jr on November 27, 2013, 06:44:36 PM

Quote from: loquitus_of_borg on November 27, 2013, 05:58:35 PM

On another note, electrum has a payto command (and a paytomany) that allows you to specify the from address. I am assuming this is essentially doing what I am talking about here, right?

This is a bug. There is no from address.

electrum help payto
Create and broadcast a transaction.
Syntax: payto [label]
can be a bitcoin address or a label
options:
--fee, -f: set transaction fee
--fromaddr, -F: send from address -
--changeaddr, -c: send change to address

Are you saying that the "feature" where I specify the fromaddr above is misnamed, or something else? I assumed that by specifying the from addr, it simply would only use unspent transaction outputs that were going to that specified address, as the inputs for the new outgoing transaction.

Is this incorrect?

It's not a feature, it's a bug. There is no use case for selecting UTXO entries based on the transaction they were created by.

loquitus_of_borg

newbie

Activity: 50

Merit: 0

electrum help payto
Create and broadcast a transaction.
Syntax: payto [label]
can be a bitcoin address or a label
options:
--fee, -f: set transaction fee
--fromaddr, -F: send from address -
--changeaddr, -c: send change to address

Are you saying that the "feature" where I specify the fromaddr above is misnamed, or something else? I assumed that by specifying the from addr, it simply would only use unspent transaction outputs that were going to that specified address, as the inputs for the new outgoing transaction.

Is this incorrect?

Quote from: Luke-Jr on November 27, 2013, 06:44:36 PM

Quote from: loquitus_of_borg on November 27, 2013, 05:58:35 PM

On another note, electrum has a payto command (and a paytomany) that allows you to specify the from address. I am assuming this is essentially doing what I am talking about here, right?

This is a bug. There is no from address.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: loquitus_of_borg on November 27, 2013, 05:58:35 PM

On another note, electrum has a payto command (and a paytomany) that allows you to specify the from address. I am assuming this is essentially doing what I am talking about here, right?

This is a bug. There is no from address.

loquitus_of_borg

newbie

Activity: 50

Merit: 0

Correction. But yes. I want to choose which of the unspent transaction outputs to "consume" in a new outgoing transaction.

On another note, electrum has a payto command (and a paytomany) that allows you to specify the from address. I am assuming this is essentially doing what I am talking about here, right?

Quote from: K1773R on November 27, 2013, 07:02:57 AM

Quote from: loquitus_of_borg on November 27, 2013, 04:46:56 AM

Well I am trying to control what coins are being consumed in a given transaction... as in which unspent inputs... but how would I do this?

Quote from: Luke-Jr on November 27, 2013, 01:56:51 AM

The point is to let you micromanage what coins (UTXO entries) you consume in a given transaction.
There is no such thing as a "from address".

by selecting the outputs you want to use...

K1773R

legendary

Activity: 1792

Merit: 1008

/dev/null

Quote from: loquitus_of_borg on November 27, 2013, 04:46:56 AM

Well I am trying to control what coins are being consumed in a given transaction... as in which unspent inputs... but how would I do this?

Quote from: Luke-Jr on November 27, 2013, 01:56:51 AM

The point is to let you micromanage what coins (UTXO entries) you consume in a given transaction.
There is no such thing as a "from address".

by selecting the outputs you want to use...

loquitus_of_borg

newbie

Activity: 50

Merit: 0

Well I am trying to control what coins are being consumed in a given transaction... as in which unspent inputs... but how would I do this?

Quote from: Luke-Jr on November 27, 2013, 01:56:51 AM

The point is to let you micromanage what coins (UTXO entries) you consume in a given transaction.
There is no such thing as a "from address".

Luke-Jr

legendary

Activity: 2576

Merit: 1186

The point is to let you micromanage what coins (UTXO entries) you consume in a given transaction.
There is no such thing as a "from address".

loquitus_of_borg

newbie

Activity: 50

Merit: 0

How do I use the command-line client?

I am not asking how to use it in general -- I have been using the standard bitcoind command line client (bitcoind) for a while. I am trying to figure out how to use this one to one key thing... send many from a specific bitcoind ADDRESS (not account) to one or more addresses, each with varying amounts, and as a bonus, specify the change to a certain address.

I thought this was the point of this release, right? What am I missing here? I need to use the command line interface.

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: behindtext on September 13, 2013, 07:54:00 PM

Quote from: Wolf0 on September 13, 2013, 07:18:07 PM

Quote from: gmaxwell on September 13, 2013, 12:55:24 PM

Can someone please work on creating a test plan and working through it so we can merge this? Sad

I would think it's been tested enough. Unless you mean that someone has to create a test plan to satisfy some bureaucratic nonsense.

it's not a matter of whether it's been behavior-tested enough in the field, it's a matter of ongoing test support, thus the request for a plan.

a test plan matters and it is not "bureaucratic nonsense". if you distribute software that breaks or has bugs creep in, especially with financial software, it reflects poorly on the developers.

It'd be pretty hard for CC to break at this point, since so many people have tested it and tried to break it. Unless you mean a test plan to expose any future bugs.

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

cozz, would you be willing to do this for an alt-coin? I have one in mind.

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Quote from: Gavin Andresen on October 23, 2013, 10:30:27 PM

Quote from: Financisto on October 21, 2013, 06:17:19 AM

IMHO I think it should be available as default to official client.

... then volunteer to run through the test plan and help shake out any bugs.

Are you saying that if I run through that test plan and confirm that it doesn't turn up bugs you'll upstream the patches?

Because if that's what you're saying, I'll do it. Please bitmessage me, I read the forum infrequently.

But if this is just another excuse/double-standard I have better things to do.

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: gmaxwell on September 13, 2013, 12:55:24 PM

Can someone please work on creating a test plan and working through it so we can merge this? Sad

I would think it's been tested enough. Unless you mean that someone has to create a test plan to satisfy some bureaucratic nonsense.

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Edit: sorry, it actually reduces the amount sent, which is the safer thing to do. I tried this twice (once exhausting the inputs, once not) and mixed up the transactions when I viewed them.

It looks like the fee source depends on the structure of the sending wallet -- apparently it will take the fee above-and-beyond the amount sent if it can, and otherwise it reduces the amount sent. It might be nice to mention this behavior to the user…

I found a small bug, although I'm running a somewhat outdated version of coin control so this might be fixed.

Select inputs for a transaction such that the inputs are just enough to fund the transaction and its fee "under ordinary circumstances". If the resulting transaction winds up being "over the size limit" the client will ask the user if they want to pay the extra 0.0005BTC but won't ask where to take the fee from the chosen inputs (since they're exhausted). Instead it appears the fee is simply taken from some other random input in the wallet, potentially compromising privacy.

FWIW, the privacy provided by the coin control client in the presence of this bug is still strictly superior to the legacy client, so this report should not in any way delay the integration of coin control into the legacy client.

Topic: Yet another Coin Control Release [CLOSED] - page 3. (Read 47431 times)