Update, 22 Sept: Still looking for a fix for OSX 10.5 users. If you are running 10.5, you should not upgrade yet.
If so, this warning should be included in the top post. (Not everyone will read page five before upgrading.)
Topic: Bitcoin-Qt/bitcoind version 0.7.0 released - page 2. (Read 25323 times)
If so, this warning should be included in the top post. (Not everyone will read page five before upgrading.)
I am having a issue deleting old addresses from the address book using version 0.7.0 on Ubuntu 12.04. Does anyone else have this issue?
A minor issue, not sure if yet reported. 0.7.0 client does not allow to transfer the whole balance, stating an incorrect initial fee (prior to ‘send’ confirmation). My example: balance 0.1739839, client does not allow to spend more then 0.1719839 (initially assumes 0.002 minimum fee), the minimum fee is in fact 0.0015 (correctly calculated after 'send' data check on 0.1719839 and overrides an earlier 'assumed' 0.002), so 0.0005 remains unspent even if you force it as a nominal fee in the settings. Initial fee miscalculation? 6.3 does not have such problem. Please check. TIA.
pm me for details if needed.
pm me for details if needed.
Update, 22 Sept: Still looking for a fix for OSX 10.5 users. If you are running 10.5, you should not upgrade yet.
updated to 0.7.0-beta
Thanks!
Thanks!
((...snip...))
Post an address, and I will cause a 3rd party to send a transaction to it in such a way that it can not be returned to me.
Post an address, and I will cause a 3rd party to send a transaction to it in such a way that it can not be returned to me.
Are you describing a scenario where your bitcoin wallet (private keys) is controlled by a third party?
Or perhaps (for example)
One could "withdraw" from their GLBSE balance to someone else's bitcoin address (to make a patment from them)
perhaps mtgox and/or other "in the cloud" wallet providers... I can only speculate. Only ever used official satoshi (bitcoinqt / bitcoind) wallet.
Yes. I have at least three accounts with services that will send coins at my command, but will not come from a key that I control, or is otherwise associated with me in any way. A return to sender on those payments will go either to the service provider, or to a random user of that service.
And that's just off the top of my head. I bet that if I looked through my password safe, I'd see plenty more accounts that I've totally forgotten.
And that's not all. Say you are making a major sale, and you want the proceeds to go into a P2SH multisig account where most of the keys are offline, or under the control of an authentication service. You get the payment and check the list, see that the coins are "tainted". Now what? You don't have the keys available to return them immediately. Oops.
As a colour blind DBA (i.e UI retarded), I dislike the startup logo.
I'd rather see the "traditional" Bitcoin icon on a light coloured (perhaps a gradient) background.
((...snip...))
Post an address, and I will cause a 3rd party to send a transaction to it in such a way that it can not be returned to me.
Post an address, and I will cause a 3rd party to send a transaction to it in such a way that it can not be returned to me.
Are you describing a scenario where your bitcoin wallet (private keys) is controlled by a third party?
Or perhaps (for example)
One could "withdraw" from their GLBSE balance to someone else's bitcoin address (to make a patment from them)
perhaps mtgox and/or other "in the cloud" wallet providers... I can only speculate. Only ever used official satoshi (bitcoinqt / bitcoind) wallet.
Please find or hire someone to update and fix the problems in it, so that it might be merged in the future. Maybe start a bounty?
+1
I would love to see this feature working.
I might start the bounty myself in the morning (or some other time) if it hasn't been started yet... After when I've slept and/or look back in this direction (bitcointalk forums) again.
Thanks for the official-like status update on the future of this feature, luke.
Is there really STILL no coin control options in this release? This is the major feature I have been waiting for for many many months and I am so disappointed that it seems to be not here ?
Please find or hire someone to update and fix the problems in it, so that it might be merged in the future. Maybe start a bounty?Today's next-test still has Coin Control barely merged in, but this will probably be the last time due to rapid bitrot.
Thanks for new version.
@kjj
huh? why not?
Are you saying you can spend someone else's coins despite not having access to the private key for their address(es)?
Edited to add:
multi-input transactions require private keys just the same as single-input. I'm not sure what you're referring to.
A rather direct, simlpified implication is that if coins are sent, the private key(s) used to generate the transaction script(s) is controlled by the sender.
huh? why not?
Are you saying you can spend someone else's coins despite not having access to the private key for their address(es)?
Edited to add:
multi-input transactions require private keys just the same as single-input. I'm not sure what you're referring to.
A rather direct, simlpified implication is that if coins are sent, the private key(s) used to generate the transaction script(s) is controlled by the sender.
Yes, that is exactly what I am saying. Post an address, and I will cause a 3rd party to send a transaction to it in such a way that it can not be returned to me.
@kjj
huh? why not?
Are you saying you can spend someone else's coins despite not having access to the private key for their address(es)?
Edited to add:
multi-input transactions require private keys just the same as single-input. I'm not sure what you're referring to.
A rather direct, simlpified implication is that if coins are sent, the private key(s) used to generate the transaction script(s) is controlled by the sender.
huh? why not?
Are you saying you can spend someone else's coins despite not having access to the private key for their address(es)?
Edited to add:
multi-input transactions require private keys just the same as single-input. I'm not sure what you're referring to.
A rather direct, simlpified implication is that if coins are sent, the private key(s) used to generate the transaction script(s) is controlled by the sender.
Bitcoin transactions do not have a sender address. They have one or more input txouts, each of which may or may not have an identifiable address it was previously sent to. Relying on this information is not portable, as it is client-dependent. If you need a refund address or some payout address, ask for it. This also prevents reuse of addresses, which is bad for Bitcoin's privacy model (not just of those whose addresses are involved).
PS: since 0.7, you can find this information using the raw transaction API.
PS: since 0.7, you can find this information using the raw transaction API.
really?
1) Are you sure that there are transactions without an identifiable sender addresses? I've never seen a single transaction like that in the blockchain.
2) "coin taint" all the way back to the original generated coin(s) in question has always been fully traceable whenever I've attempted.
3) Coin control is a desired / requested / needed feature. The ability to control which source coins are spent in transactions and whatnot.
4) there is no four. except maybe "please qualify your assertion as I've addressed in #1"
What you have is the last address that received those coins. This is not the same thing as a sender address.
Things get even more silly if you think about transactions with multiple inputs and/or outputs.
Bitcoin transactions do not have a sender address. They have one or more input txouts, each of which may or may not have an identifiable address it was previously sent to. Relying on this information is not portable, as it is client-dependent. If you need a refund address or some payout address, ask for it. This also prevents reuse of addresses, which is bad for Bitcoin's privacy model (not just of those whose addresses are involved).
PS: since 0.7, you can find this information using the raw transaction API.
PS: since 0.7, you can find this information using the raw transaction API.
really?
1) Are you sure that there are transactions without an identifiable sender addresses? I've never seen a single transaction like that in the blockchain.
2) "coin taint" all the way back to the original generated coin(s) in question has always been fully traceable whenever I've attempted.
3) Coin control is a desired / requested / needed feature. The ability to control which source coins are spent in transactions and whatnot.
4) there is no four. except maybe "please qualify your assertion as I've addressed in #1"
hmmm, it sounds like there may be an OSX-specific problem.
What is the previous known working version?
Was that an official OSX build from Gavin, your own build, or a third party build?
Thanks.
0.6.3 also works fine here.What is the previous known working version?
Was that an official OSX build from Gavin, your own build, or a third party build?
Thanks.
0.7 was the official build from bitcoin.org.
That last question was asking who built the previous, working version? Who built 0.6.3? Gavin, you, or other?
Both of my copies, 0.6.3 and 0.7.0, were official releases too.
i have problems with p2pool !
Quote
2012-09-20 00:18:17.974000 p2pool (version 3.1)
2012-09-20 00:18:17.974000
2012-09-20 00:18:17.974000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'user'...
2012-09-20 00:18:18.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:21.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:24.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:27.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:30.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:33.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:36.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:17.974000
2012-09-20 00:18:17.974000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'user'...
2012-09-20 00:18:18.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:21.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:24.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:27.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:30.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:33.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:36.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
P2pool 3.1 is not compatible with bitcoind 0.7,
and since getmemorypool is removed, it thinks its version is too old.
You can upgrade p2pool to 5.0 now.
i have problems with p2pool !
Quote
2012-09-20 00:18:17.974000 p2pool (version 3.1)
2012-09-20 00:18:17.974000
2012-09-20 00:18:17.974000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'user'...
2012-09-20 00:18:18.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:21.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:24.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:27.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:30.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:33.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:36.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:17.974000
2012-09-20 00:18:17.974000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'user'...
2012-09-20 00:18:18.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:21.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:24.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:27.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:30.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:33.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
2012-09-20 00:18:36.505000 > Error: Bitcoin version too old! Upgrade to v0.5 or newer!
We updated today from 6020 to 70003 all went smooth, thank you very much!
One thing we can't figure out. Why bitcoind API can't return the senders address from a transaction?
We are still using third parties for this operation which is far from optimal. I believe that lot of others have the same needs as I read in other posts.
One thing we can't figure out. Why bitcoind API can't return the senders address from a transaction?
We are still using third parties for this operation which is far from optimal. I believe that lot of others have the same needs as I read in other posts.
Bitcoin transactions do not have a sender address. They have one or more input txouts, each of which may or may not have an identifiable address it was previously sent to. Relying on this information is not portable, as it is client-dependent. If you need a refund address or some payout address, ask for it. This also prevents reuse of addresses, which is bad for Bitcoin's privacy model (not just of those whose addresses are involved).
PS: since 0.7, you can find this information using the raw transaction API.
Tremendous.
Jump to: