Bitcoin Forum
December 09, 2016, 12:20:46 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
Author Topic: .  (Read 36302 times)
phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
June 25, 2012, 09:41:37 AM
 #101

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

blockchained.com ■ bitcointalk top posts
1481242846
Hero Member
*
Offline Offline

Posts: 1481242846

View Profile Personal Message (Offline)

Ignore
1481242846
Reply with quote  #2

1481242846
Report to moderator
1481242846
Hero Member
*
Offline Offline

Posts: 1481242846

View Profile Personal Message (Offline)

Ignore
1481242846
Reply with quote  #2

1481242846
Report to moderator
1481242846
Hero Member
*
Offline Offline

Posts: 1481242846

View Profile Personal Message (Offline)

Ignore
1481242846
Reply with quote  #2

1481242846
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481242846
Hero Member
*
Offline Offline

Posts: 1481242846

View Profile Personal Message (Offline)

Ignore
1481242846
Reply with quote  #2

1481242846
Report to moderator
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
June 25, 2012, 02:21:32 PM
 #102

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)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
June 25, 2012, 03:22:10 PM
 #103

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
Jr. Member
*
Offline Offline

Activity: 52


View Profile
June 25, 2012, 03:25:05 PM
 #104

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
*
expert
Offline Offline

Activity: 2086



View Profile
June 25, 2012, 03:28:09 PM
 #105

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 Offline

Activity: 1820


Ian Knowles - CIYAM Lead Developer


View Profile WWW
June 25, 2012, 03:29:26 PM
 #106

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
49er
Jr. Member
*
Offline Offline

Activity: 52


View Profile
June 25, 2012, 03:44:24 PM
 #107

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

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 Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
June 26, 2012, 09:54:59 AM
 #108

* ShadowOfHarbringer is watching this.

EnergyVampire
Full Member
***
Offline Offline

Activity: 210



View Profile
June 26, 2012, 10:49:34 AM
 #109

Interesting...

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
June 26, 2012, 11:55:32 AM
 #110

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 Offline

Activity: 1834



View Profile
June 26, 2012, 12:25:57 PM
 #111

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 27, 2012, 06:33:45 PM
 #112

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

phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
June 30, 2012, 04:50:59 AM
 #113

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

blockchained.com ■ bitcointalk top posts
zebedee
Donator
Hero Member
*
Offline Offline

Activity: 666



View Profile
July 07, 2012, 05:45:38 AM
 #114

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.
Sr. Member
****
Offline Offline

Activity: 449



View Profile
July 07, 2012, 08:58:22 PM
 #115

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
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
July 07, 2012, 09:14:12 PM
 #116

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

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

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
July 07, 2012, 09:45:41 PM
 #117

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

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 Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
July 07, 2012, 11:44:53 PM
 #118

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

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

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

phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
July 09, 2012, 07:47:13 AM
 #119

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

blockchained.com ■ bitcointalk top posts
phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
September 24, 2012, 02:08:16 PM
 #120

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

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!

blockchained.com ■ bitcointalk top posts
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!