Topic: My (and many others') rant about Bitcoin-QT (Read 3535 times)

You can use rawtx to do the samething

I would appreciate if developers add a new command that sends bitcoins from exact address to another two addresses (payee's and own address to get change back ). Like this:


I really miss this command because every time I want to send private transaction I have to do stupid manipulations extracting the address and adding it to a new wallet.

Thanks for this thread. I thought I'd lost about 6 btc based on the difference between what the blockchain says my address has and what bitcoin-qt says. I'm now *kinda* thinking everything is OK, but will investigate getting the keys out of my wallet just to be sure (I'll think I'll do it offline, too )

Wow, did not expect this level of discourse
Personally, I use blockchain.info not Electrum - I was implying "anything but Bitcoin-QT".
We even got the dev in here
Just please add an option to see ALL addresses in my wallet.dat file.

John, I value your work greatly, which is why I am featuring it as one of my lectures in my course. Every community has members who do not appreciate the contributions of others. Do not infer that this is the standard. We, as a whole, deep appreciate your participation and effort and need you to continue with both passion and vigor.

Not necessarily. Even a simple send requires wallet unlocking.
The command is not so much dangerous because it unlocks the wallet, but because the private key leaves the wallet.

Thank you.

I noticed here https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list ''dumpprivkey'' command requires unlocked wallet. Should other / all commands requiring unlocked wallet like ''importprivkey'' or ''sendfrom'' be avoided to prevent data interception?

I can see how that would be annoying if you truncate the original quote.

If you wanted to paraphase that, it would be more accurate to truncate it this way:

"I actually don't think Bitcoin-Qt should exist as an all-in-one program."

And then there was this part:

If the reference client was split into a stack of applications at the boundaries that make sense, I think Bitcoin-Qt would be redundant, since it would not offer any features that aren't already being provided by other clients and especially since it doesn't offer any kind of offline wallet capability. That's just a guess though, and in my original post I did include a proposal (faster release schedule for bitcoin-qt compared to bitcoind and walletd) that could lead to me changing my mind.

Because after using it, the key will exist in two places 1) in the wallet 2) whereever you copy it.
Were someone else to import that key with "importprivkey" into another wallet, you'd have the "private key shared by two wallets" problem.
Apart from the you and the person you shared it with, as the key has been copied in plaintext, it could be intercepted by a third party, and it would be a race who spends the coins quickest.

Now we are getting to the heart of the matter. Many wiki articles and answers in the forum say what to do and what not to do, but rarely back these commandments with easy to understand logical / rational argumentation.

Why shouldn't I be using ''dumpprivkey''?

No, it's not. The problem is a lack of easy-to-understand documentation (F1 Help) and lack of video tutorials that would explain:

a) the practicalities and idiosyncrasies of the system (e.g. you can revoke an unconfirmed transaction - how can a non-techie newbie know this if not by accident / luck?) and
b) would explain operation that can be performed with Bitcoin-Qt (change addresses, commands, etc.).

I will spend 1 or 2 weeks to get a basic understanding while searching this forum and asking silly questions (and driving moderators crazy) that had already been asked a thousand times, while I could very well gain the same or better knowledge (i) by watching two or three videos done by someone focused on teaching and not on himself and his excitement and (ii) by reading F1 Help in two hours.

This forum would have been 100 times smaller if there were 3 good videos on how to use Bitcoin-Qt.

I am not complaining though 

Thank you.

OK, then it's fine. Questions are good, certainly better than rants
Yes. Exactly.
Because of the reasons I mentioned, such as inadvertent private key sharing. Use transactions to send coins to people.
It means don't use "dumpprivkey". Ever. (I meant exporting privkeys, not exporting addresses)
For (a) and (b) you can use them. That's exactly what they're for. They're just a ledger, so you can have say 20 coins in account A and 10 coins in account B. After spending 5 coins from account A there will be 15 coins in the account left... etc..

Apart from spending from them, you can move coins between accounts arbitrarily with the "move" command  (as kjj mentions). This moves the coins in the internal ledger.

You can also receive coins on accounts, so if you create a receiving address for account B, give it to someone, they send coins to it it will be credited to account B.

What I was trying to say is that they have zero association with low-level implementation details such as private keys and inputs, and do not provide any isolation on that level. So if you want to do hiding like in (c) they are not the appropriate choice. You need separate wallets in that case.

Indeed -- the internal modularization needs to have no impact at all on the interface. At most there will be an advanced option to point it at an external block chain daemon instead of the built-in one, so you can decide to trust someone instead of fetch your own chain.

This has all been discussed many times, is doable, and work is underway, the only limitation really is development and testing time. I sincerely wish more people would join in development instead of ranting on forums. Too many armchair devs here.

Making it user friendly is tough indeed; much of the recent client work is focused on higher-level abstractions, such as the payment protocol, so that it is possible to pay to merchants/people instead of addresses.

I am not concerned. Just asking questions to find out how the system works and how I can make a practical use of it. Why my interest in ''what address the coins are on''? - if I ever wanted to conclude a contract to purchase a car with an even less Bitcoin-knowledgable user I would put my (the payer's) address in the contract so that the seller could not argue in the court that the address from which he received the money wasn't mine. This is my silly newbie's reasoning. I am not concerned - just asking questions.


In this event of two addresses and two privkeys in two different Bitcoin_Qts, I am correct to assume that the winner is the one of the two users / owners  who spends the bitcoins deposited to the address faster? The other guy loses?


Why not? Because I might lose / damage such privkey or it might get stolen or for yet other reasons?


What does it mean in practice / real life ''to export addresses as a means of sending coins''. I lack the jargon.


My first guess (proved false by you) was that Bitcoin accounts could be used like this:
a) you have a wife and a child: from acc #1 you manage your operations, from acc #2 you manage your wife's operations, from acc #3 you manage your offspring's operations, there is also acc #4 for the lady your wife shouldn't know about
b) you run three stores: and you assign each account and addresses within this account to a particular outlet,
c) you travel a lot: you can safely use and report acc #1 in any jurisdiction, acc #2 is a secret one,
d) etc...

Thanks

That said, I'm all about the client-server architecture for trusted local networks. But it should be a separate product for more advanced users. The default and official client should be as easy to use for non-technical people as possible.

Bitcoin is already too complicated for general population. That includes people not understanding how clients, wallets, addresses, change addresses, etc. work. That includes people not knowing how to easily buy BTC for fiat money. And so on. It really needs to become much, much simpler to be usable to most people.

Now you want to introduce another technical barrier and requirement to install a separate server software and have it running on some kind of server machine (last time I checked most normal people didn't have a home server) in order to actually be able using a client software. Good luck with making my parents adopting bitcoin if we'll go in that direction.

I agree with your post, except that part. You make good points and further modularization, and bootstrapping as SPV client would be good things, and are in the planning. There is some work on a separate blockchain daemon, might make it to 0.10. But how do you get from there to "it shouldn't exist at all"? Are you trying to troll me?

Snotty replies such as yours really take away my motivation to work on this stuff at all. I went back to this forum after a long hiatus to help people, but this gets me annoyed really really fast.

I actually don't think Bitcoin-Qt should exist at all, at least the way it is currently implemented as an all-in-one program. The reference client is built around a user case that doesn't match how people actually use computers.

Most people do most of their computing as part of a trusted LAN with N users, either at home or at work. These users do their computing on M devices each.

If M=N=1 then the design of Bitcoin-Qt would make sense, but actually that's a rare exception.

There is no absolutely no reason for a single LAN to store N*M copies of the blockchain, and attempt to maintain N*M connections to the outside P2P network.

I think bitcoind/Bitcoin-Qt should be split into modular components that better reflect the real-world use case.

You need one component that connects to, and participates in the P2P network. This same component can also be in charge of storing the blockchain. It doesn't need, and shouldn't have, anything to do with wallets. Call  this component "bitcoind" and advise users to install one copy per LAN as an always-on service. (1 copy)

You need a component that keeps track of a user's keypairs and the balances associated with them. Call this component "walletd" and advise users to install it on every device, with a separate instance running in the background for each users on that machine. (N*M copies)

Finally you need end-user applications. These can be command-line based, or graphical (Qt). These need to be installed on every device, but don't need to run all the time - just when the user wants to do something.

If this separation was achieved and Bitcoin-Qt was just a GUI interface with no blockchain management or P2P functionality, then it would be just one of many alternatives that could perform the same task. I question whether or not it would still be needed at this point, but in any case it would be much easier to upgrade and improve since it could have a release schedule independent of the other two modular components.

1.  Incorrect.  Accounts are a purely local bookkeeping measure.  You can associate one or more addresses with a given account, but that just means that new incoming payments to that address are added to that account balance.

2.  This entire question is based on a faulty premise.  Coins are not owned by accounts.  When you spend, the account you specify is decreased by the amount of the spend.  The coins used for the spend have absolutely no bearing on the account system. 

Start with a new wallet.  Generate a new address, associate it with account "A".  Receive 100 BTC to that address.

Default account: 0 BTC
Account "A": 100 BTC

Now create a new address, associate it with account "B".  Now spend 50 BTC, specifying account "B".

Default account: 0 BTC
Account "A": 100 BTC
Account "B": -50 BTC

At this point, your wallet also has a change address in it, with a 50 BTC UTXO that can be spent.  That address is not associated with any account, but since you'll never see it, you can't give it out to receive coins anyway.

Also note that at each step, the sums of the accounts was equal to the wallet balance.  0 + 100 = 100 and 0 + 100 - 50 = 50

You could use the move RPC command to "transfer" 1,000,000 BTC from acocunt C to account D.

Default account: 0 BTC
Account "A": 100 BTC
Account "B": -50 BTC
Account "C": - 1,000,000 BTC
Account "D": 1,000,000 BTC

And again, the sum works out.