Bitcoin Forum
December 10, 2016, 06:55:43 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Development roadmap  (Read 4760 times)
Dude65535
Full Member
***
Offline Offline

Activity: 126


View Profile
March 06, 2011, 06:33:03 PM
 #21

Should click-to-pay auto fill the amount as well as the address?

If it does I think it would be a good idea to have a setting for "Require password for payments larger than X". Mainly just to slow the process down and give people a moment to sanity check the amount.

1DCj8ZwGZXQqQhgv6eUEnWgsxo8BTMj3mT
1481396143
Hero Member
*
Offline Offline

Posts: 1481396143

View Profile Personal Message (Offline)

Ignore
1481396143
Reply with quote  #2

1481396143
Report to moderator
1481396143
Hero Member
*
Offline Offline

Posts: 1481396143

View Profile Personal Message (Offline)

Ignore
1481396143
Reply with quote  #2

1481396143
Report to moderator
Be very wary of relying on JavaScript for security on sites such as blockchain.info and brainwallet.org. The site can change the JavaScript at any time unless you take unusual precautions, and browsers are not generally known for their airtight security.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481396143
Hero Member
*
Offline Offline

Posts: 1481396143

View Profile Personal Message (Offline)

Ignore
1481396143
Reply with quote  #2

1481396143
Report to moderator
1481396143
Hero Member
*
Offline Offline

Posts: 1481396143

View Profile Personal Message (Offline)

Ignore
1481396143
Reply with quote  #2

1481396143
Report to moderator
1481396143
Hero Member
*
Offline Offline

Posts: 1481396143

View Profile Personal Message (Offline)

Ignore
1481396143
Reply with quote  #2

1481396143
Report to moderator
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
March 06, 2011, 06:51:22 PM
 #22

Another feature we need IMO is the ability to reclaim payments that aren't going through, and/or to reissue payments with a higher transaction fee. (We also need basic support for transaction fees.) As the network gets busier this will become important.

Hal Finney
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 06, 2011, 07:44:35 PM
 #23

Yes, that's definitely higher priority than other nice-to-haves as it's possible to get yourself stuck currently with transactions that won't commit but that you can't reclaim.

It's the (currently disabled) sequence numbers feature, right? That lets you broadcast new versions of a transaction, presumably with a higher fee than before. For reasons I don't fully understand seqnos are on the tx inputs, not the tx itself.
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
March 06, 2011, 08:35:04 PM
 #24

Another feature we need IMO is the ability to reclaim payments that aren't going through, and/or to reissue payments with a higher transaction fee. (We also need basic support for transaction fees.) As the network gets busier this will become important.
+1
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 06, 2011, 10:32:06 PM
 #25

Another feature we need IMO is the ability to reclaim payments that aren't going through, and/or to reissue payments with a higher transaction fee. (We also need basic support for transaction fees.) As the network gets busier this will become important.

+100 agreed.  This should be a high priority, IMO.  Here's my own, off-the-cuff, probably-wrong theory:

Create transactions with a specified lifetime, either in wall clock time or number of confirmed blocks.

If the transaction is not recorded in a block by the deadline (24 hours or 144 blocks?), all nodes will refuse to relay it and miners refuse to incorporate it, thus giving the user the opportunity to resend it with a proper fee.

In general, transaction fees -- from a user perspective -- is still a bit opaque, and easy to get wrong.

It would be nice to have deterministic behavior for transactions that are not incorporated immediately.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 06, 2011, 11:51:36 PM
 #26

Should wallet encryption be done using GPG or RSA + AES?

With RSA + AES you'd still have to store the private key somewhere. My inclination would be to store them inside the wallet but now that means you're only protected by a password.
Tril
Full Member
***
Offline Offline

Activity: 212


View Profile
March 07, 2011, 09:35:52 AM
 #27

define click-to-pay?

You're browsing the web and see a link or button that says "Pay now with Bitcoin"-- you click it, and... stuff happens.  Where that stuff does NOT involve copying and pasting anything (I know WE all know how to copy and paste, but a surprising number of computer users don't) and certainly doesn't involve trying to type in a 35-character bitcoin address.


two cases. 1. user has the client: client installation adds handler to browsers for certain URIs to launch bitcoin sendtoaddress <parameter>. Depends on standard ways to add handlers to browsers and also on setting up RPC by default and the password in bitcoin.conf.  This depends on actually having a client installer, that doesn't exist yet, AFAIK.  When there is an installer, it can offer the option to setup the URI handler in various browsers and clearly inform the user of the newly enabled listening localhost port 8332 and random password written to bitcoin.conf (similar to vidalia setting up a cookie to talk to the tor daemon). For security, the bitcoin client GUI should by default require confirmation before sending payment, if GUI is active and a sendtoaddress RPC is given. Advanced users should be able to turn off the confirmation. [EDIT: this was hastily thrown together and it needs more thought to get security right]

2. user has no client and uses an online service (mybitcoin or vekja) for the wallet. Each site will need to publish a bookmarklet (javascript code) the user can click to enable mapping bitcoin: URIs to be handled by their site. If this is not possible each site will need to publish a browser addon.  Either way, case 2 has nothing to do with the bitcoin client program, but both cases should use a standardized URI, we just need to choose bitcoin:, bitcoin://, btc: or btc:// - I vote for the first one.
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
March 07, 2011, 10:09:49 AM
 #28

Just giving my two cents, I agree that the DNS-like feature is not high priority, but resending and reclaiming transactions is (should be in a 1.0)

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 07, 2011, 10:35:17 AM
 #29


Transaction date-stamp appearing in client to be in international standard format DD-MM-YY not MM-DD-YY, or selectable in options.

BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
March 07, 2011, 02:49:38 PM
 #30

In case anyone hasn't seen it yet, there is already Bitcoin URI scheme developed, though I'm not sure to what extent: https://en.bitcoin.it/wiki/URI_Scheme
Jim Hyslop
Member
**
Offline Offline

Activity: 98


View Profile
March 08, 2011, 02:00:55 AM
 #31

Should wallet encryption be done using GPG or RSA + AES?

With RSA + AES you'd still have to store the private key somewhere. My inclination would be to store them inside the wallet but now that means you're only protected by a password.
There is a discussion on github about this. Jeff Welling had suggested the possibility of using a GPG public key with the secret key stored externally.

My inclination aligns with yours - keep it self-contained. I was thinking the simplest way would be to hash the user's pass phrase and use that as a symmetric key to encrypt the private keys (or any other sensitive information that needs to be stored in the wallet). As an advanced option, we could allow the user to specify a GPG public key from their existing GPG keyring.

As far as only being protected by a password... well, the knowledgeable users will either choose a very long pass phrase, or use an external GPG key. It's the users who choose weak passwords who would be the most at risk.

Next time you're using an ATM or POS PINpad that has the numbers silk-screened on the keys (as opposed to being molded into the keys), you'll notice that the "1" is almost obliterated, "2" is mostly obliterated, and "3" and "4" are quite well worn. That pretty much tells you how many peoples use 1234 or 1111 for their PINs. Those are the people who would also choose weak passwords for their wallets. And I don't see any technical way to shield them from the risks they are opening themselves up to.

On the lighter side of bad passwords: http://www.youtube.com/watch?v=K95SXe3pZoY

Like my answer? Did I help? Tips gratefully accepted here: 1H6wM8Xj8GNrhqWBrnDugd8Vf3nAfZgMnq
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
March 08, 2011, 02:50:12 AM
 #32

I know the bitcoin<->Berkeley DB code pretty well, so I'll volunteer to do the "Import a backed up wallet" feature.

If you don't mind, i was planning on extending my dumpprivkey/importprivkey patch (see other thread) a bit so it can export and import whole wallets, one of the next days.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
March 08, 2011, 08:49:29 AM
 #33


Transaction date-stamp appearing in client to be in international standard format DD-MM-YY not MM-DD-YY, or selectable in options.

True! This thing of putting months before days is damn confusing... when will you english folks learn to use proper formats and the metric system?  Cheesy

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
foo
Sr. Member
****
Offline Offline

Activity: 409



View Profile
March 08, 2011, 10:49:53 AM
 #34


Transaction date-stamp appearing in client to be in international standard format DD-MM-YY not MM-DD-YY, or selectable in options.

True! This thing of putting months before days is damn confusing... when will you english folks learn to use proper formats and the metric system?  Cheesy
Oh FFS...

1. The ISO standard date format is YYYY-MM-DD.
2. The current client uses the local date format, at least on Windows.
3. The English do put the day before the month, you are talking about Americans.

I was going to keep quiet, but... http://xkcd.com/386/  Wink

I know this because Tyler knows this.
QuantumMechanic
Member
**
Offline Offline

Activity: 110


View Profile
March 08, 2011, 11:27:14 AM
 #35

Another feature we need IMO is the ability to reclaim payments that aren't going through, and/or to reissue payments with a higher transaction fee. (We also need basic support for transaction fees.) As the network gets busier this will become important.

+100 agreed.  This should be a high priority, IMO.  Here's my own, off-the-cuff, probably-wrong theory:

Create transactions with a specified lifetime, either in wall clock time or number of confirmed blocks.

If the transaction is not recorded in a block by the deadline (24 hours or 144 blocks?), all nodes will refuse to relay it and miners refuse to incorporate it, thus giving the user the opportunity to resend it with a proper fee.

In general, transaction fees -- from a user perspective -- is still a bit opaque, and easy to get wrong.

It would be nice to have deterministic behavior for transactions that are not incorporated immediately.
I like the finite lifetime transaction rule.

I was thinking it would be nice if when a user is entering a transaction, the fee could be adjusted from within the same window while giving a concomitant estimate of the expected time for the transaction to clear (to have, say, 6 confirmations), based on the parameters of the proposed transaction, and the block chain data from the past, say, 24 hours.  This would help to make the purpose of transaction fees more transparent to users, and the fees would be set closer to where they actually need to be.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
March 08, 2011, 07:36:49 PM
 #36

In case anyone hasn't seen it yet, there is already Bitcoin URI scheme developed, though I'm not sure to what extent: https://en.bitcoin.it/wiki/URI_Scheme
It's pretty much finalized, and in real world use (IIRC, mainly in phone UIs)

batfink
Newbie
*
Offline Offline

Activity: 3


Just a random name :)


View Profile
March 10, 2011, 07:57:25 AM
 #37

i kinda like the idea of using AES with a password/passphrase, though i understand the issues with passwords and especially users that choose really bad weak passwords.

How about we make brute forcing the password more difficult by making it more computationally expensive... maybe by taking the password... hashing it with a short random salt of maybe 20bits.... with 1,048,575 possibilities, that salt would take maybe a second for a standard computer to guess, but would greatly slow down any attempt at brute forcing a password.

secondly a short blacklist of the most common passwords like "password" and encouraging people to use a pass-phrase rather than a password would probably be a good idea.
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
March 10, 2011, 08:04:19 AM
 #38

In case anyone hasn't seen it yet, there is already Bitcoin URI scheme developed, though I'm not sure to what extent: https://en.bitcoin.it/wiki/URI_Scheme
It's pretty much finalized, and in real world use (IIRC, mainly in phone UIs)
[/quote]
Ok. I'm playing around implementing this into WalletBuddy right now... When a bitcoin: URL is clicked, I'm queuing the payment and allowing the user to send queued payments when a wallet is open. Think it will be cool in the mean time.

Any idea how Linux registers URL handling?
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
March 10, 2011, 09:00:40 AM
 #39

I was talking with ArtForz about the making a new tx with a higher fee a week or so ago.  He mentioned that nodes never broadcast new txes unless they are just receiving it for the first time and nodes do not save txes that haven't been confirmed to disk.  Thus, when a node restarts, all of the txes which it previously had in its memory pool will be lost and one can resubmit a tx to the network once enough nodes have forgotten the previous tx.  ArtForz mentioned that he reboots his mining bitcoind once every 24 hours for dynamic ip reasons and in his tests he could resubmit a new tx after only around 24 hours due to network turnover.  Thus, if we make sure the major mining nodes restart on a regular basis, we could simply make a new tx with the same inputs but a higher fee very easily without any major changes to the network.  Just my 2 cents.

Also, the URI sceme needs to be included better in the client.  Maybe make it default for opening bitcoin:// URIs? Or maybe just a ff/chrome/safari/etc plugin which grabs bitcoin: URIs and connects to a local rpc daemon to send the funds?

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 10, 2011, 09:16:04 AM
 #40

Thus, if we make sure the major mining nodes restart on a regular basis, we could simply [...]

It does not seem prudent to enshrine a "reboot it frequently!" policy as part of standard operating procedure.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Pages: « 1 [2] 3 »  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!