Topic: . - page 3. (Read 40384 times)

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.

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

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

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.

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.

Interesting...

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.

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).

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

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.

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.


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.

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)

maybe not stop but take one step after the other.

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

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)?

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.