phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2012, 09:41:37 AM |
|
... and fixed so you can specify transactions, not just addresses.
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.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2012, 02:21:32 PM |
|
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
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2012, 03:22:10 PM |
|
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.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
49er
Newbie
Offline
Activity: 52
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2012, 03:25:05 PM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2012, 03:28:09 PM |
|
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
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2012, 03:29:26 PM |
|
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). ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
49er
Newbie
Offline
Activity: 52
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2012, 03:44:24 PM |
|
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? ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) 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
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2012, 09:54:59 AM |
|
* ShadowOfHarbringer is watching this.
|
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8684
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2012, 11:55:32 AM Last edit: June 26, 2012, 12:11:21 PM by 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
Legendary
Offline
Activity: 2126
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2012, 12:25:57 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 27, 2012, 06:33:45 PM |
|
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 ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 30, 2012, 04:50:59 AM |
|
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 ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) 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
Donator
Hero Member
Offline
Activity: 668
Merit: 500
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 07, 2012, 05:45:38 AM |
|
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.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 07, 2012, 08:58:22 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 07, 2012, 09:14:12 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Actually i remember reading somewhere that this will be implemented in 0.7. Am I wrong ?
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 07, 2012, 09:45:41 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 07, 2012, 11:44:53 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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" ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) (Just fooling around here, don't mind me)
|
|
|
|
phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 09, 2012, 07:47:13 AM |
|
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
Legendary
Offline
Activity: 1708
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 24, 2012, 02:08:16 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.0thanks luke!
|
|
|
|
|