Pages:
Author

Topic: Development roadmap - page 2. (Read 5428 times)

Hal
vip
Activity: 314
Merit: 3853
March 06, 2011, 02: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.
full member
Activity: 126
Merit: 101
March 06, 2011, 02: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.
legendary
Activity: 1652
Merit: 2216
Chief Scientist
March 06, 2011, 01:37:19 PM
#20
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.
full member
Activity: 213
Merit: 100
March 06, 2011, 12:26:09 PM
#19
define click-to-pay?
full member
Activity: 126
Merit: 101
March 05, 2011, 11:42:15 PM
#18
For click-to-pay, what about finalizing details for a bitcoin:// uri scheme, and letting the client handle those requests? Any idea of an easy way to get that to work with an online wallet, though?

If I recall right mailto:// works both for a separate email program or web based email. So I would imagine however that is accomplished might solve that problem.
sr. member
Activity: 294
Merit: 250
March 05, 2011, 10:40:11 PM
#17
For click-to-pay, what about finalizing details for a bitcoin:// uri scheme, and letting the client handle those requests? Any idea of an easy way to get that to work with an online wallet, though?
legendary
Activity: 1652
Merit: 2216
Chief Scientist
March 05, 2011, 10:30:41 PM
#16
The solution for sending coins to people is ...

Cool... but Hal just convinced me we don't need that feature for bitcoin 1.0.

Is anybody willing to commit to actually implementing any of these?

I know the bitcoin<->Berkeley DB code pretty well, so I'll volunteer to do the "Import a backed up wallet" feature.
joe
member
Activity: 64
Merit: 10
March 05, 2011, 08:33:14 PM
#15
  • design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "[email protected]")

The solution for sending coins to people is at https://bitcointalksearch.org/topic/send-bitcoins-to-an-unknown-recipient-3427
I envision adding a "wallet" tab to the client, which lists every bitcoin bundle in wallet.dat, and if you double click any bundle you can: (1) copy the private key for that bundle so you can email it to someone, (2) split out a different amount, (3) combine with another bundle, (4) reissue. Very similar to that other digital currency ecache.
legendary
Activity: 1441
Merit: 1000
Live and enjoy experiments
March 05, 2011, 08:07:53 PM
#14
I suppose if we figure out how to make click-to-pay work for both the "I'm using an online wallet service" and the "I'm using the client" cases, then users won't have to know how to copy&paste addresses and human-type-able addresses won't be critical.
Maybe a little bit off-topic, but I think better usability is essential to bitcoin's success.

Highly recommend this book: http://www.amazon.com/Change-Function-Technologies-Others-Crash/dp/B000NA6U2O/ref=sr_1_1

Book description:
"After years of studying countless winners and losers, Coburn has come up with a simple idea that explains why some technologies become huge hits (iPods, DVD players, Netflix), but others never reach more than a tiny audience (Segways, video phones, tablet PCs). He says that people are only willing to change when the pain of their current situation outweighs the perceived pain of trying something new."

"In other words, technology demands a change in habits, and that’s the leading cause of failure for countless cool inventions. Too many tech companies believe in "build it and they will come"— build something better and people will beat a path to your door. But, as Coburn shows, most potential users are afraid of new technologies, and they need a really great reason to change."
 
legendary
Activity: 1526
Merit: 1129
March 05, 2011, 08:03:56 PM
#13
By the way, one way to let me send coins to [email protected] is to leverage the old direct-to-IP mechanism. Example:

1) Download EC public key from http://acm.org/bitcoin-transact/gavin. Optionally, if that results in a 404, fall back to http://directory.bitcoin.org/acm.org/gavin

2) Create a transaction with OP_CHECKSIG as the output, broadcast

3) Gavin claims it by sending a tx with just a signature in the scriptSig.

All clients should still be able to recognize these sorts of transactions. All we've done is replace the direct IP-to-IP connectivity with a well-known HTTP endpoint. Supporting this scheme is as simple as creating a directory on a web server.

It can be extended to include not just an EC key but an RSA key in the downloaded file too. Then you can send a message by encrypting it, POSTing it somewhere (like back to the acm.org server if the downloaded file advertises that it supports that), and including the hash in the transaction before an OP_DROP. This way even though you only advertise a single key, you can still find out who sent you coins.

I'm not claiming this is easier or better than having some simple web browser integration mind you. It'd still require some setup and ultimately copy/pasting a BitCoin address isn't much different to copy/pasting an email address.

I suspect there's various interesting ways you can avoid relying on base58 addresses using the scripting language.
newbie
Activity: 42
Merit: 0
March 05, 2011, 06:14:30 PM
#12
What about adding the public/private mode like chrome/firefox?  It could default to privacy mode which would be the current setup, but could be toggled to public mode where you can have accounts where an address in that account can be used for both sending and receiving.  I think this would really simplify a lot of bitcoin, open it up to a much broader audience, and make room for a lot more services to build on top.

legendary
Activity: 1526
Merit: 1129
March 05, 2011, 06:10:07 PM
#11
I think glueing the browser to the node software is a lot easier than coming up with some complicated address mapping scheme.

I'm pretty familiar with how we do DoS resistance at work, but traditional DoS and BitCoin DoS are very different problems. There are just so many ways to do it, and best of all, nobody really knows what the capacity of the network is :-)
legendary
Activity: 1652
Merit: 2216
Chief Scientist
March 05, 2011, 06:07:37 PM
#10
design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "[email protected]")
This might be nice but I don't see it as a prerequisite for 1.0.

I suppose if we figure out how to make click-to-pay work for both the "I'm using an online wallet service" and the "I'm using the client" cases, then users won't have to know how to copy&paste addresses and human-type-able addresses won't be critical.

RE: DoS resistance:  please DO keep thinking about it; I'm not a networking expert (in fact, if you know any networking experts, see if you can get them thinking about it....).
Hal
vip
Activity: 314
Merit: 3853
March 05, 2011, 05:29:52 PM
#9
design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "[email protected]")

This might be nice but I don't see it as a prerequisite for 1.0.

In the discussion on BitDNS, there was resistance to overloading the main chain as a title registry. Another chain a la BitDNS could be used to map general strings to btc addresses, as well as domain names.

One issue is it pretty much has to be first come first served. Whoever grabs [email protected] first, gets it. There wouldn't be any way to verify ownership of the address.
legendary
Activity: 1526
Merit: 1129
March 05, 2011, 04:03:45 PM
#8
It's easy to evolve the protocol. Just change the format if the peer reports its protocol version as >whatever number.

And yes that would be a good improvement. A getmerklebranch message would also be very useful for client mode as that'd let you see 0/unconfirmed transactions like today. Otherwise in client mode you'd have to wait for a block to see you received coins.
full member
Activity: 171
Merit: 127
March 05, 2011, 04:02:14 PM
#7
Perhaps really really low priority, but I want to remind you about redundant transmission of transactions with each block. May be it's better to solve this sooner rather than later.

My proposal is to modify 'block' message to contain only transaction hashes. After that, 'getdata' can be used to further acquire missing transactions from block's sender.

Unfortunately I don't see how this can be done without breaking current protocol.
legendary
Activity: 1526
Merit: 1129
March 05, 2011, 03:51:55 PM
#6
To clarify, this is a code development roadmap, not project development. Translated docs and better marketing materials would be great but it's not relevant to v1 of the software.
newbie
Activity: 42
Merit: 0
March 05, 2011, 03:47:25 PM
#5
any bug are always highest priority

Marketing and education are highest priority. We need more docs to be translated into different languages.
legendary
Activity: 1526
Merit: 1129
March 05, 2011, 03:46:04 PM
#4
I'm still thinking DoS resistance through. Gavin and Satoshi have pondered that the most so for now I'm happy to just sit back and let them figure it out :-)

I like the roadmap, though I agree it's somewhat arbitrary. The client mode will need a lot of work even after it's implemented, we don't really want to force users to choose when they start the software as 99% will have no way to understand what that choice means. A Skype/Kazaa type approach in which all nodes start as "clients" and then later choose themselves whether to become supernodes with full block chain copies would be better (as long as there's a semi-obscure way to force it for miners).

Client mode and DoS resistance are closely related anyway. One reason the current network has so many problems with "spam" is that the network is constrained to the capabilities of its worst nodes so we need all these artificial limits followed by systems to try and handle the artificially constrained capacity. Introducing a concept of self-selecting supernodes will allow the network to scale up significantly further - until it starts hitting natural hardware limits, most likely cpu or disk iops. At that point we'll hopefully have at least prototype versions of distributed supernodes.
Hal
vip
Activity: 314
Merit: 3853
March 05, 2011, 03:32:32 PM
#3
Is there anything we need to do for robustness against spam/flooding attacks? I thought [mike] had some ideas.
Pages:
Jump to: