Topic: multisig functionality (Read 658 times)

Electrums change to BIP32 (still due in 2.0?) will help with the uncompressed key issue. BIP32 uses compressed keys, so perhaps the fee issue won't be as bad then.

The only better solution is to have rules based on the current fee structure that always checks and minimizes the waste.  For example if the dust was 5000 satoshis......but you could save it with a fee of 3000 satoshis.

What do you think?

Currently any transaction with less than minimum fee will give a warning message preventing send.
However, if you set mintxfee to 0 and then try to send 0.5 BTC with only a 0.50000001 BTC output, the client will send:

Input: 0.50000001
Output: 0.5
Miner's fee: 0.00000001

Because a miner fee is merely the difference between sum of all inputs and outputs. You don't actually set the tx fee. The miners just take all unclaimed bitcoins in the transacions.

good explanation... i get it.

that solution you posted doesn't seems ok, 
but what happens if there's no required fee for a .5 transaction
to begin with and your address has .5000001.... now you can't
tack on the dust to the miner fee.  what happens then?
does it just force a fee to handle the dust?

also what does bitcoind do?

Let's say the only bitcoins I have in my whole electrum wallet is 0.50010001 BTC and I received it in 1 transaction to 1 of my addresses.

Let's then say I would like to send 0.5 BTC to a friend and the minimum fee is 0.0001 BTC (yes I know right now less than half the network will accept 0.00001 BTC as minimum)

If there was no such thing as "dust" I would do the following:

Input#1: 0.50010001 BTC used up.
Output#1: 0.5 BTC to friend
Output#2: 0.00000001 BTC to self
Miner's fee: 0.0001 BTC
Inputs - (Outputs + Miner's fee) = 0 = OK

Then I would be using my output fully.

However, there is a rule in Bitcoin that states: "If any one of the outputs is less than 5430 satoshis (0.0000543 BTC) this transaction is spam, don't include it in a block."

So the scenario above would create a "dust" transaction. As miner's have to include the whole transaction, and that transaction contains an output smaller than 5430 satoshis.

To deal with this, some people have proposed "using another output in the transaction to merge with the dust and make it big enough to send."

That would be something similar to if the above wallet ALSO had another usable utxo that was, let's say, 0.01 BTC.

The idea states:

Input#1: 0.50010001 BTC used up.
Input#2: 0.01 BTC used up.
Output#1: 0.5 BTC to friend
Output#2: 0.01000001 BTC to self
Miner's fee: 0.0001 BTC
Inputs - (Outputs + Miner's fee) = 0 = OK

However, adding a new input to the transaction adds 140 bytes to the transaction (along with the 34 bytes for the change output as compared to including it into the miner's fee) (107 once we get support for compressed addresses). Any transaction under 1024 bytes is ok with the minimum fee, but even if you go over by one byte, (1025) then you should pay 2 x the minimum fee to get proper priority.

Which would make the trade off of adding an input in order to save 1 satoshi seem illogical.


Anywho, if you can think of a better solution, great. But for now the transaction is like this:

Input#1: 0.50010001 BTC used up.
Output#1: 0.5 BTC to friend
Miner's fee: 0.00010001 BTC
Inputs - (Outputs + Miner's fee) = 0 = OK

I dont fully get it.

Why arent we just putting the dust output back into another used wallet address?

If you have a good method of eliminating dust transactions (#543) (any transaction with an output less than 5430 satoshis) feel free to send a pull request.

it's just that the methods being proposed were generally: Add another input so the change output won't become dust and won't be included in the fee.

However, Electrum currently uses uncompressed addresses, so adding a whole new input would most likely push the recommended fee up a tick, so it would be cheaper to just pay the dust in the tx fee.

I personally find it to be a non-issue, but if you have a good idea, feel free to submit a PR.

Thanks Thomas.

I took a look at the open issues.

Many of them are just questions, like:

"It would be cool if Electrum had contact names"
https://github.com/spesmilo/electrum/issues/451

This issue open since Nov 22, 2013.

At what point is a decision made, should
we include this feature, or close the issue?

I'm just trying to figure out what to try to work on

another example:  issue 543, Debura said "I think its a non issue"
back in March, and nothing has been done , issue is still open...

if you are a programmer, use and test the git head version.
you will see which features are already developed, and you will be able to submit changes and fixes.

Add interesting plugins.

Look at how each plugin in the plugins folder interfaces with the main UI using run_hook, and see if you can create any useful plugins first.

If they are good enough, they will probably get merged into the main UI.

Also if you see any issues that haven't been resolved and you are able to debug them and fix them, please submit the fixes in a pull request.

Edit:

If you can figure out this one, it'd be awesome. I didn't notice, but all of a sudden the Wrong password UI stopped popping up and only shows up in the terminal.

https://bitcointalksearch.org/topic/no-wrong-password-message-612521

Ah , ok...so they already got this covered.

How do you suggest I contribute to the electrum project?

2.0 will support 2 of 2 and 2 of 3 multisig wallets that are created deterministically.

Thomas is also preparing a service to help facilitate multisig as well.

Not to mention the Kivy Android GUI project will facilitate that as well.

See the roadmap here:
https://bitcointalksearch.org/topic/electrum-state-of-the-alloy-427617

Is anyone developing this?  working on this?

I would love to work on this if the Electrum devs agree and want contributors.