Bitcoin Forum
March 19, 2024, 09:46:48 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Preparing for wx --> qt switch  (Read 6496 times)
piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1344


aka tonikt


View Profile WWW
September 21, 2011, 06:55:48 PM
 #41

To save the further anguish I propose that anyone who wants to be treated seriously should explain how his proposed improvement will deal with the following pseudo-code (from wallet.cpp & ui.cpp):

CWallet::SendMoney() {
    grab_the_wallet_lock();
    solve_inverted_knapsack_problem_to_select_the_best_coin_subset();
    fee = compute_the_required_transaction_fee();
    yesno = ::ThreadSafeAskFee(fee);
    commit_transaction_and_release_lock(yesno);
}
This is how I see it:
 * grab_the_wallet_lock(); - not needed
 * solve_inverted_knapsack_problem_to_select_the_best_coin_subset() - not needed (see below)
 * fee = compute_the_required_transaction_fee() - just take the value from the user interface
 * yesno = ::ThreadSafeAskFee(fee) - useless (always answer 'yes - i'm sure what i set')
 * commit_transaction_and_release_lock(yesno) - this is the only thing you need to do. so you first talk to the wallet, saying that you want to send this money to this address. the wallet does the solve_inverted_knapsack_problem_to_select_the_best_coin_subset and returns you the signed transaction. then the UI app forwards it to the blockchain server.
and then you also need to resend to the blockchain server those transactions that have not been mined yet.
and also there are other things that you need to think about Smiley
but basically the idea of splitting it into a blockchain/transaction server, a wallet and a native GUI app seems to me the most reasonable to go with Smiley

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
1710841608
Hero Member
*
Offline Offline

Posts: 1710841608

View Profile Personal Message (Offline)

Ignore
1710841608
Reply with quote  #2

1710841608
Report to moderator
1710841608
Hero Member
*
Offline Offline

Posts: 1710841608

View Profile Personal Message (Offline)

Ignore
1710841608
Reply with quote  #2

1710841608
Report to moderator
No Gods or Kings. Only Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710841608
Hero Member
*
Offline Offline

Posts: 1710841608

View Profile Personal Message (Offline)

Ignore
1710841608
Reply with quote  #2

1710841608
Report to moderator
bcforum
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
September 21, 2011, 11:10:03 PM
 #42

I have a semi-constructive proposal. There has been a lot of whining and quarter-baked proposals floating about changes and improvements to the Satoshi client. It is hard to judge whether these proposals are made by incompetent programmers or just programmers that haven't thoroughly reviewed the code and its architecture.

To save the further anguish I propose that anyone who wants to be treated seriously should explain how his proposed improvement will deal with the following pseudo-code (from wallet.cpp & ui.cpp):

CWallet::SendMoney() {
    grab_the_wallet_lock();
    solve_inverted_knapsack_problem_to_select_the_best_coin_subset();
    fee = compute_the_required_transaction_fee();
    yesno = ::ThreadSafeAskFee(fee);
    commit_transaction_and_release_lock(yesno);
}

Basically, show us that you know how to solve the inversion of control problem that is posed by this code. For extra credit, show us that your modification will deal properly with chain reorganization while waiting inside the UI for the user to accept the fee.

If you don't know how to solve those problems please send your proposal to /dev/null or nul:, as the case may be.

I think John Smith did a feat of software engineering comparable to doing a successful face transplant on a Frankenstein.

An interesting problem, perhaps we could crowdsource a solution.

Oh wait, nobody without a masters in software engineering is qualified to make suggestions on the architecture of the client.

http://www.tomsguide.com/us/video-game-foldit-research-aids-virus-folding,news-12584.html

You might be interested to note most of the gamers didn't have degrees in molecular biology.

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1060



View Profile
September 22, 2011, 03:02:16 AM
 #43

Oh wait, nobody without a masters in software engineering is qualified to make suggestions on the architecture of the client.

http://www.tomsguide.com/us/video-game-foldit-research-aids-virus-folding,news-12584.html

You might be interested to note most of the gamers didn't have degrees in molecular biology.
Interesting link, albeit pretty much content-free. I'm going to have to assume two things:

1) "gamers" were actually CS students on the BSc or MSc track.
2) "gamers" didn't have the attitude "lets fuck big pharma if they give us a chance"

Here we have a crowd developing a revolutionary financial solution and the prevailing attitude is: fuck accountants and the GAAP-horse they rode on. I think I know how that is going to end: they lawyer will tell them that the only words they are allowed to speak are: "Yes, your honor!". It is very much similar to the new drivers who only learn how to drive after they had to stand before the judge.

I haven't worked with anyone from entertainment industry background for many years. But from the past I remember well that there were clear distinction between at least two groups:

A) those who could persuasively discuss the drawbacks and benefits of duo-quaternions and 4-by-4 homogenous matrices.
Z) those who had very twitchy fingers and traded rants: "OpenGL rules and you are paid MSFT shill!" vs. "DirectX rules and you are SGI troll!".

Do you (or any one else here) have an idea or suggestion how the game development community separates wheat like (A) from the chaff like (Z)?

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
bcforum
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
September 22, 2011, 03:51:33 AM
 #44

As I understand the problem, in order to separate the wallet/GUI from the block chain you need to draw a line between them.

The wallet has:
    High security
    The macro transaction as defined by the user (number of coins, dst address, maximum tx fee)
    All the valid addresses associated with the signing key
    The signing key
The wallet needs:
    An exact list of the micro transactions required to execute the macro transaction
------------------------------------------------------------------------------------------------------------------------------
The block handler has:
    Internet connectivity
    A list of all addresses in the universe and how many coins are associated with each of them
The block handler needs:
    A signed list of micro transactions to be included into the block chain


So, it seems like the following steps are required to perform a send transaction:

1) User inputs the number of coins, destination address and maximum transaction fee (optionally the addresses to take the coins from)
2) Wallet requests number of coins in each address (from block handler) starting with the oldest until sufficient coins are available to complete transaction
3) Wallet builds micro transaction list, calculates TX fee, and prompts user if calculated fee is too high
4) Wallet sends signed micro transaction list to block handler
5) Block handler validates transactions and reports back to user success/failure. Note that the block handler does this for transactions from the internet anyway.
6) If valid (block chain hasn't reorg'd) transaction is broadcast to world

Does this solve your inversion of control problem? I believe it addresses my security concerns regarding the signing key being attached directly to the internet. There is an issue with the wallet needing to request all coins in all addresses in order to update the current balance. I prefer the extra workload this incurs over having all the wallet addresses resident in the block handler where they could potentially be stolen.

PS a better link http://www.wired.com/medtech/genetics/magazine/17-05/ff_protein?currentPage=all

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1060



View Profile
September 22, 2011, 05:41:48 AM
 #45

Does this solve your inversion of control problem?
No, it doesn't. My short example assumed that the "client" maintains the current integrated architecture. If you want to split it between wallet-less "bitcoind" and block-chain-less "bitcoinui" then you have to explicitly specify which protocol you are going to use between the two halves. You cannot just hide behind a row of dashes. It has to be a two-way communication protocol that handles (a) receiving coins (b) sending coins (c) chain extension (d) chain reorganization (e) all other miscellaneous tasks most importantly "getwork" for mining. So far nobody had made any workable proposal. There is some sketch by Genjix & friends: http://bitcoinconsultancy.com/libbitcoin/libbitcoin/

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
September 22, 2011, 05:46:24 AM
 #46

The GUI is trivial. If there is a cross-platform backend, writing a GUI will be just a matter of several days.
Trivial, hah, I thought the same in the first two weeks of working on this, when I had made some mockups in Qt Designer.  Then reality hit me.

I think John Smith did a feat of software engineering comparable to doing a successful face ansplant on a Frankenstein.
You have to start somewhere uh Smiley Have many face transplants have you done where the patient was trying to strangle you  Cheesy

Which is also why I'm done bickering about whether Qt was the right choice, why not the zillion other UI libraries, why I chose this specific URL scheme etc. If you have anything to add, you know where the "pull request" button is.

I've implemented the most-requested features and removed the most common annoyances, and the UI as a major concern is now addressed.

Now let's move on to helping Alex Waters with his QA stuff so that we can refactor the core code *with* the assurance of unit tests.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
September 22, 2011, 01:45:42 PM
 #47

Does this solve your inversion of control problem?
No, it doesn't. My short example assumed that the "client" maintains the current integrated architecture. If you want to split it between wallet-less "bitcoind" and block-chain-less "bitcoinui" then you have to explicitly specify which protocol you are going to use between the two halves. You cannot just hide behind a row of dashes. It has to be a two-way communication protocol that handles (a) receiving coins (b) sending coins (c) chain extension (d) chain reorganization (e) all other miscellaneous tasks most importantly "getwork" for mining. So far nobody had made any workable proposal. There is some sketch by Genjix & friends: http://bitcoinconsultancy.com/libbitcoin/libbitcoin/

Back in June or so, several projects popped up intending to make secure hardware wallets.  As far as I can tell, there has been absolutely zero progress from any of them, for exactly the reason that 2112 mentions.  Pay special attention to the one I bolded.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
September 23, 2011, 06:44:28 AM
 #48

As far as I can tell, there has been absolutely zero progress from any of them, for exactly the reason that 2112 mentions. 
This is completely usual in open source. Many times, the reason is simply that people give up, or don't have enough commitment to one project and let it linger. There were also zillions of "user friendly alternative bitcoin UIs" that popped up around when I started coding om bitcoin-qt. Most of those have been abandoned a long time ago.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
vv01f
Sr. Member
****
Offline Offline

Activity: 314
Merit: 250


View Profile
September 23, 2011, 07:59:31 AM
 #49

Back in June or so, several projects [..] intending to make secure hardware wallets.  [..]there has been absolutely zero progress from any of them[..]
There is a one-way hardware-wallet: casascius' coin Wink
And I would handle smartphones or even tablets as "like" a hardware-wallet - as they are portable enough. or is there a contrary definition?

donations to me please send via bitcoin 1vvo1FDwSAwNdLVA1mFkM7v76XPZAAUfb
a good European exchange: bitcoin.de (ref-link)
genjix
Legendary
*
expert
Offline Offline

Activity: 1232
Merit: 1071


View Profile
September 23, 2011, 09:11:40 PM
 #50

Hey John,

I don't know if you've been following my project libbitcoin:

https://bitcointalk.org/index.php?topic=30646.0
https://gitorious.org/libbitcoin/libbitcoin

I've been making good progress.

Anyway I just wanted to say that you should try to make bitcoin-qt as generic as possible wherever you can with replaceable backends. That means in the future you'll have more developers focused around developing one GUI (and pooling effort) rather than many competing clients running in parallel.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!