Re: [Bitcoin-development] Monetary Authority for Bitcoin
+1 On Mon, Dec 9, 2013 at 2:06 PM, Gavin Andresen gavinandre...@gmail.comwrote: On Tue, Dec 10, 2013 at 8:01 AM, Ryan Carboni ryan.jc...@gmail.comwrote: The exchanges that are kept track of could be hard coded into Bitcoin or the miner could choose, how this works is not something I'm personally focused on. That is like saying We need a way to travel around the world quickly. There will be an anti-gravity technology; how this works is not something I'm personally focused on. Or, in other words, you are ignoring exactly the sticky, difficult problem that would have to be solved for your proposal to have any chance of working. -- -- Gavin Andresen -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] btc name server
I'd raised this topic before suggesting to leverage DNS as its kinda useful for mapping names to numbers. Expect no support. -rick On Fri, Aug 2, 2013 at 1:40 PM, Chris Evans aaxiomfin...@gmail.com wrote: wonder if it would be good idea to have a alias to wallet id nameserver in the client software where a person can use a english name to describe a wallet public key address? and the software can use it to look up the wallet id. wallet ids are hard to remember/recall. -chris http://tawhakisoft.com/ -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blockchain as root CA for payment protocol
I prefer to leverage the signing of the (.) root in the DNS tree. The amount of effort in signing the root holds more weight than building a CA off the bitcoin blockchain. If you want to associate identifiers for payment addresses I suggest putting those in DNSSEC signed records in the DNS. For routing around x.509 CAs I suggest participating in the DANE working group in the IETF. -rick On Fri, Feb 8, 2013 at 2:03 AM, Timo Hanke timo.ha...@web.de wrote: There have been proposals to use the blockchain to establish identities. firstbits is a simple example. I would like to announce a project that extends this idea to turn the blockchain into a root CA that can sign arbitrary certificates. The purpose is to use these certificates in the payment protocol, where some might consider traditional centralized root CAs unsatisfactory. Code is here: https://github.com/bcpki Technical specification and full-length examples are found in the wiki. I therefore spare myself from repeating the details here, even though, of course, discussion about those details is welcome on this list. Excerpt from README.md follows: First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses). This part has surely been done elsewhere as well and is orthogonal to the goal of this project. What is new here is the signatures _under_ the certificates. We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates. Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs). This seems to make signature lookup and verification reasonably fast: it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course). Payment methods include: static bitcoin addresses, client-side derived payment addresses (pay-to-contract), pay-to-contract with multisig destinations (P2SH) Full-length real-world examples for all payment methods are provided in the tutorial pages. These examples have actually been carried out on testnet3. For further details and specifications see the wiki. timo hanke -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish wal...@stani.sh wrote: X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? Of the three currently published proposals, all are essentially IANA registry proposals. We are currently working with IETF staff, with open offers of support from multiple well funded commercial bodies, to transition these proposals through to IANA management. I hate to inform you that you have been mislead. The IETF and the IANA do not operate as you outlined above. Having spent too many years within ICANN/IETF/IANA I can assure you are mistaken. Your drafts are expired and it appears that there is no support for a finance working group in the IETF. -rick -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins andypark...@gmail.com wrote: [snip] You've been unfair, the equivalent of your u...@authority.tld is https://authority.tld/user; or https://user.authority.tld/; or https://google.com/bitcoin/user; or any of an infinite number of other variations that _I_ as the mapper get to choose rather than whoever wrote the BIP; all of which are arguably no less elegant than that simple email. There is no equivalent in the other direction though. For someone who want's to supply the TX to their mapping server... where does it go in u...@authority.tld? actually there are many differences. Specifying a standard using a HTTP(s) transport for a look-up isn't something that has been done in the PATH portion of the URI and that I was pointing out that there is *NO* RFC that specifies such for a look-up provide the inverse of many protocol specifications that did *not* choose that methodology. What has happened is various schemes are specified, developed and deployed. I am sure you are familure with many. sip:// ftp:// etc:// many are described at http://en.wikipedia.org/wiki/URI_scheme NAPTR records (see http://en.wikipedia.org/wiki/NAPTR_record) are another area that deserves research for those that desire URI schemes. Understand that I am mearly advocating that as a group this work be done in standards development process, and that IBANN is one such effort. -rick -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On Fri, Dec 16, 2011 at 1:52 PM, Khalahan k...@dot-bit.org wrote: The number of proposals is not infinite, here are their problems : - FirstBits : centralized - DNS TXT Records : DNSSEC is required to have a minimum of security, limits usage to engineers, limits usage to some domain names (i won't be able to use a gmail address for example, because i don't control the gmail.com domain) The same goes for http(s) one would not be able to use http://google.com/user unless google offers the services. ALSO look at DANE for getting around the certificate requirement for https - Server Service (DNS + a daemon) : Same as DNS TXT records DNS TXT are not the only way forward, also registry/registrars can facilitate. - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to check the full certificate chain and access a list of up-to-date certificate authorities (installed on the OS or provided with bitcoin). And don't forget the CA model is not 100% reliable (several CA hacked this year + possible government control...). This most likely relies on a paid, valid certificate (that expires), no self signed certs. I admit that running a secured https server with a valid CA signed cet is as simple/hard as running a DNSSEC authority zone. using a x.509 certificate to secure a bitcoin transaction removes some of the anonymity of the transaction by allowing the lookup to identify the certification, ca, crl etc thus connecting a transaction/bitcoin address to the cert and to its issuing authority. No matter the frequency of the destination bitcoin address changing. IMNSHO, leveraging CAs to secure http to provide a lookup translation to a bitcoin address will only erode anonymity. While DNS is connected to whois there are provision for hiding behind a proxy where to the best of my knowledge there are no such provisions offered by CA's issuing x.509 certificates. Should self signed cers be allowed or encouraged only decreases security. Clearly DANE would be the only way to mitigate this situation but then you are back to relying on DNSSEC to bind the x.509 cert. wash, rinse, ... -rick - IP Transactions : This proposal seeks to enable DNS lookups for IP transactions = same as above I know that providing a namecoin daemon with bitcoin is not the lighter solution, but, if a better one existed i guess it would have already been integrated into bitcoin... (see in what state is my first attempt with the HTTPS proposal : Send payments to emails, urls and domains in GUI - khalahan opened this pull request April 20, 2011) So, what's next ? Le 16/12/2011 20:54, slush a écrit : Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy. For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced ?handle= parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iopanything_else=True And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers... Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too. Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it. slush -- Best Regards, Khalahan http://dot-bit.org/ -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Why don't just... bitcoin://url.without.explicitly.specifying.provider bitcoin://alias@provider bitcoin://IIBAN@authorizedBitcoinInstitution ?? By the way, I don't like the fact that a single authorized institution needs to map the IIBANs to bitcoin addresses. The IANA is a good institution to rely on for mapping things, much history and wise execution there. -rick -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
I was looking at the wiki entry for this and noticed that your description of DNSSEC is incorrect. It is an internet standard and is widely deployed in the root (.), many TLDs, ccTLDs and second leverl domains. Also understand when the IETF or ICANN adopts new (we worked on DNSSEC no less than 10 years) standard the horizon is at least 20 years. Nothing and I really mean nothing is adopted in mass over shorter time scales. I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs you can look up the following record _btc.rick.wesson.us (from r...@wesson.us) which yealds ; DiG 9.6-ESV-R4-P3 _btc.rick.wesson.us txt ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45136 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;_btc.rick.wesson.us. IN TXT ;; ANSWER SECTION: _btc.rick.wesson.us.299 IN TXT BTC=1\; 1GCVXLfF1TcpnnDLJRHk845NZhuJWQTnUD ;; Query time: 147 msec while this isn't a secured zone, any leverage of DNSSEC would require the application to have direct hooks into the stub-resolver, rather than just leveraging the OS's implementation. just some food for thought... -rick 2011/12/14 Jorge Timón timon.elvi...@gmail.com: What if we specify bitcoin to make it easier for software (maybe the browser, a plugin for the browser, the bitcoin client analyzing the clipboard...) to easily detect that you expect a bitcoin address when going to url? If puted in the bitcoin client, the bitcoin:// is optional (? and can also be replaced by http ?) since from the context you already expect an address or an url that will give you the address. In the browser: bitcoin://address bitcoin://rest_of_url In the bitcoin client: address rest_of_url bitcoin://address bitcoin://rest_of_url http://rest_of_url ?? Maybe in the bitcoin client you can put any site and the client downloads the web to look for occurrences of bitcoin:// (? or just valid addresses ?) in it. It caches and shows them to you to decide what to do with each one. I have used other programs (jdownloader) that read the clipboard looking for patterns in links and is very convenient. Maybe then parameters for the client can be added to this. bitcoin://address?amount=10.53 bitcoin://rest_of_url?amount=10.53green_address=r bitcoin://rest_of_url?amount=10.53green_address=rgreen_address_list=address1,address2,address3 Whatever the community have planned for bitcoin URIs. -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
understand that not *everyone* wants or will adhere to that best practice and in my NSHO it isn't. -rick 2011/12/14 Luke-Jr l...@dashjr.org: On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)... The hard part of using DNS will be sticking to the standard good practice of using a new address for every transaction. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Building a node crawler to map network
I've got minna patches for nio based on bitcoinj. I've enumerated the network a few times and am working on a DNS seed service as well as some weather reports. Happy to start a branch when the committers are ready. -rick On Tue, Sep 6, 2011 at 12:42 AM, Steve shadders@gmail.com wrote: Hi All, I started messing around today with building a node crawler to try and map out the bitcoin network and hopefully provide some useful statistics. It's very basic so far using a mutilated bitcoinj to connect (due me being java developer and not having a clue with c/c++). If it's worthwhile I'll hack bitcoinj some more to run on top Netty to take advantage of it's NIO architecture (netty's been shown to handle 1/2 million concurrent connections so would be ideal for the purpose). Hoping to a get a bit of input into what would be useful as well as strategy for getting max possible connections without distorted data. I seem to recall Gavin talking about the need for some kind of network health monitoring so I assume there's a need for something like this... Firstly at the moment basically I'm just storing version message and the results of getaddr for each node that I can connect to. Is there any other useful info that can be extracted from a node that's worth collecting? Second and main issue is how to connect. From my first very basic probing it seems the very vast majority of nodes don't accept incoming connections no doubt due to lack of upnp. So it seems the active crawl approach is not really ideal for the purpose. Even if it was used the resultant data would be hopelessly distorted. A honeypot approach would probably be better if there was some way to make a node 'attractive' to other nodes to connect to. That way it could capture non-listening nodes as well. If there is some way to influence other nodes to connect to the crawler node that solves the problem. If there isn't which I suspect is the case then perhaps another approach is to build an easy to deploy crawler node that many volunteers could run and that could then upload collected data to a central repository. While I'm asking questions I'll add one more regarding the getaddr message. It seems most nodes return about 1000 addresses in response to this message. Obviously most of these nodes haven't actually talked to all 1000 on the list so where does this list come from? Is it mixture of addresses obtained from other nodes somehow sorted by timestamp? Does it include some nodes discovered by IRC/DNS? Or are those only used to find the first nodes to connect to? Thanks for any input... Hopefully I can build something that's useful for the network... -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
