Re: [Bitcoin-development] Monetary Authority for Bitcoin
+1 On Mon, Dec 9, 2013 at 2:06 PM, Gavin Andresen wrote: > On Tue, Dec 10, 2013 at 8:01 AM, Ryan Carboni wrote: > >> 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=111408631&iu=/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=111408631&iu=/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 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=49501711&iu=/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=49501711&iu=/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 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
> > We are not establishing an IETF working group, which is an option that > was explored prior to the Paris meeting and has been sidelined at > present for depth-of-bureaucracy by the backing commercial entities. > Rather, we are establishing a top-level IANA registry group. This is > not anticipated by the IETF old-guard working with us to be either (a) > controversial or (b) possible to block. My last note in this sub-thread. There are no IANA registry groups, there is no such thing, and no way to form one. The IETF can ask the IANA to form a registry but these things take lots of support and take a long time, and these are only created through standards track RFC. ICANN runs the IANA and there is no such framework that you elude to. Review http://www.iana.org/protocols/ If you are applying for a gTLD, good luck with that. -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] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish 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] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 4:26 PM, Mike Hearn wrote:
>> Perhaps we should agree to talk about everything _except_ that first?
>
> Yeah, alternatives to X.509 chains don't interest me right now except
> in the sense that they should be cleanly implementable with future
> extensions.
>
> So if you care about DANE or DNSSEC or custom PKI infrastructures or
> whatever, rather than proposing them as replacements here (DOA), just
> figure out how you would extend the protocol in Gavins mail in a
> future extension. If you can't see a clean way to do it then let's
> discuss that. If you can think of a way to do it then let's table it.
> Better replacements can come in later BIPs.
The only part that has an x509 cert associated is in the invoice message.
message Invoice {
//repeated bytes x509chain = 1;
optional string domainName =1;
repeated Output outputs = 2;
required uint64 time = 3;
optional uint64 expires = 4;
optional bool single_use = 5 [default = true];
optional string memo = 6;
optional string receiptURI = 7;
optional bytes merchant_data = 8;
}
Removing that and adding a opaque string called domain name, or
identityName would be sufficient to move the conversation forward
without the x.509 baggage.
-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] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 4:31 PM, Luke-Jr wrote: > On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote: >> Another nifty thing is that it can associate a cert to a domain and a >> payment address, if one were to put said address in the DNS :) >> >> Now I am sure the majority of the bitcoin user-base desires anonymity, >> but as a merchant I would like to be knowable and wouldn't mind it if >> my identity and those of my transactions were "known" and associated >> both with my domains and x.509 cert. In most commercial transactions >> (which include many of those that leverage invoices) identity is >> important, at least for the merchant. > > Anonymity isn't a feature we claim to have, nor a goal of the project for the > most part. Using a single Bitcoin address has many problems besides non- > anonymity: your customers are denied basic privacy and there is no good way to > guarantee the user who says he paid you really did (since transaction ids are > public record, anyone can claim they sent it). > > In short, it is for the most part considered a rule to always use a unique > address per transaction or at least per customer. putting payment addresses in the DNS does not require that only a single address be used. This is an assumption and a possible use case, but there is no requirement that payment addresses must be 1:1 associated. -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] Payment Protocol Proposal: Invoices/Payments/Receipts
I hope you all take a moment to see what DANE leverages with DNSSEC and SelfSigned x.509 certs. DANE provides the capability for any entity to associate a self signed certificate with a domain name. This capability removes the critical path of whitelists and/or Root CA certs. Another nifty thing is that it can associate a cert to a domain and a payment address, if one were to put said address in the DNS :) Now I am sure the majority of the bitcoin user-base desires anonymity, but as a merchant I would like to be knowable and wouldn't mind it if my identity and those of my transactions were "known" and associated both with my domains and x.509 cert. In most commercial transactions (which include many of those that leverage invoices) identity is important, at least for the merchant. -rick On Mon, Nov 26, 2012 at 3:52 PM, Jeff Garzik wrote: > On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen > wrote: >> This is the next big "lets all agree to do things the same way" thing >> I think we should tackle. I'm particularly looking for feedback from >> other bitcoin client developers, even if it is just a quick "looks >> reasonable, if everybody else is going to do it then I will >> (eventually) too..." > > Comments: > > 1) Payment message should include ability to specify the transaction > _or_ a transaction id sent via normal means over the network. > > 2) I think a significant bitcoin userbase will want to operate outside > the full root-CA chain. Just look at https:// websites now. > Self-signed certs are quite common, because it is easier, while being > more secure than http:// > > So some provision for self-signed certs, a use case in wide use > elsewhere, or equivalent thereof, seems reasonable. > > -- > Jeff Garzik > exMULTI, Inc. > jgar...@exmulti.com > > -- > 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 -- 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] Payment Protocol Proposal: Invoices/Payments/Receipts
X.509 has some problems we have recent experience with. I'd prefer to
leverage something like DANE which looks to help with assertions
around certificates and creates an option around the CAs and x.509
roots.
-rick
On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen wrote:
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
>
> Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
> suggestions and brainstorming.
>
> This document is online at https://gist.github.com/4120476
>
> If you respond to this message, please be considerate of people who
> subscribe to the digest version of this mailing list and trim your
> response.
>
>
> Invoices, Payments and Receipts for Bitcoin Transactions
>
>
> This document proposes protocol buffer-based formats for signed,
> authenticated "invoices" and "receipts" -- requests for payment, and
> proof-of-payment.
>
> Separate documents propose an extension to the Bitcoin URI syntax and
> new MIME types to support them.
>
> Motivation
> ==
>
> The idea of a "payment protocol" to improve on Bitcoin addresses has
> been around for over a year. Users have been asking for some features
> in this proposal (like the ability to provide a refund address so
> overpayments or refunds can be returned to customers without the need
> to ask them for their address) for two or three years, and have
> started to work around shortcomings in the Bitcoin payment process
> with creative (but inefficient) uses of transactions.
>
> The key features of this proposal are:
>
> + Requests for payment (Invoices) are tied to authenticated identities
> using the only widely-deployed identity authentication system we have
> right now (X.509 certificates signed by root certificate authorities)
> + Invoices include a user-friendly description of what the payment is for
> + Payments include where refunds should be sent
> + At the end of the payment process, the customer holds a
> cryptographically signed Receipt that can be used as proof-of-payment
> if there is any dispute with the merchant.
>
>
> Specification
> =
>
> Invoice/SignedInvoice
> -
>
> An Invoice is a request for payment from a merchant to a customer:
>
> ::
>
> message Output {
> optional uint64 amount = 1;
> required bytes script = 2;
> }
>
> amount: Number of satoshis (0.0001 BTC) to be paid. If not given
> or zero, then the customer will be asked how much to pay.
>
> script: a "TxOut" script to which the customer should direct payment.
> This will normally be one of the standard Bitcoin transaction script
> (e.g. pubkey OP_CHECKSIG).
>
> ::
>
> message Invoice {
> repeated bytes x509chain = 1;
> repeated Output outputs = 2;
> required uint64 time = 3;
> optional uint64 expires = 4;
> optional bool single_use = 5 [default = true];
> optional string memo = 6;
> optional string receiptURI = 7;
> optional bytes merchant_data = 8;
> }
>
> outputs: one or more outputs where Bitcoins are to be sent.
>
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
>
> time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was created.
>
> expires: Unix timestamp after which the Invoice should be considered
> invalid. If not given, the Invoice may be re-used until the earliest
> certificate expiration date in the X509chain.
>
> single_use: If true, this Invoice should be used for only one payment.
> If false, it may be added to the user's address book and used
> repeatedly until it expires (e.g. for donations or a recurring
> payment).
>
> memo: UTF-8 encoded, plain-text (no formatting) note that should be
> displayed to the customer, explaining what this Invoice is for.
>
> receiptURI: Secure (https) URI where a Payment message (see below) may
> be sent to obtain a SignedReceipt as proof-of-payment.
>
> merchant_data : Arbitrary data ignored by the client that may be used
> by the merchant to identify the Invoice.
>
> ::
>
> message SignedInvoice {
> required Invoice invoice = 1;
> required bytes signature = 2;
> }
>
> A SignedInvoice is an Invoice signed using the private key
> corresponding to the public key in the first certificate in the
> x509chain and the HMAC SHA-256 algorithm.
>
> When a Bitcoin client receives a SignedInvoice, it must authorize
> payment by doing the following:
>
> 1. Validate the x509chain certificate chain up to it's list of root
> certificate authorities
> 2. Validate that the time on the customer's system is before Invoice.expires
> 3. Display the "Common Name" (CN) s
Re: [Bitcoin-development] [BIP 15] Aliases
You are describing the problem DANE addresses, see http://tools.ietf.org/html/draft-ietf-dane-protocol-12 Using Secure DNS to Associate Certificates with Domain Names For TLS Abstract TLS and DTLS use PKIX certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. For those of you against DNSSEC, DANE leverages it significantly. The point I have been attempting to make is if one to rely on HTTPS, leveraging DANE will allow you to mitigate CAs and use self signed cers but you will need to leverage DNSSEC to bind the self signed cert using DANE and if you are going to rely on DNSSEC for DANE to support HTTPS, why not short-circut this madness and just publish your identifiers and secure the zone via DNSSEC and link in a stub resolver in the client. Short story: transform u...@authority.tld --> _btc.user.athority.tld TXT 1z A short i-d is probably a better way to explain, so I will task myself to do that. -rick On Mon, Dec 19, 2011 at 6:46 AM, solar wrote: > I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a > good idea and (historical implementation bugs aside) the concept is > technically sound and secure. What is a bad idea (in my opinion) is to trust > a software vendor to decide who you should trust.. thus it is a bad idea for > bitcoin software to promise any trust. > > The part where the concept becomes flawed is trusting 3rd parties who have no > relationship with you, to serve your interests. Now I'm just generalizing > here and this is not universally true.. but internet CAs just want to sell > certificates - they generally don't care beyond that, and they abuse the > certificate validity dates to charge more money. All this is done under the > guise of wanting to provide a secure experience to users without a prior > relationship to the entity being identified. I propose that trying to follow > this paradigm in bitcoin alias resolution is a bad idea because it tries to > solve 2 problems at once, one of which does not have any 'good' solution, and > forces a specific policy. > > First, we need to resolve an alias to a bitcoin address somehow.. but > secondly we need to establish trust with the entity doing the alias > resolution - to make sure that we can trust the response. > > When resolving an alias you will have to query an untrusted server, possibly > being proxied by an 'attacker'. Presumably, an x.509 certificate will be > presented, possibly self signed or chained off a self generated CA or > whatever else.. but if it's your first contact then there is no possible way > to know if it's correct or not. You would have to retrieve the correct > public key of the CA to compare to first, possibly out of band. Get it from > my website, compare it to my business card, send me an email and I'll send it > to you, or get it from some other source using some other pre existing trust > (a centralized and possibly private directory perhaps). The point is, the > reason there is so much disagreement is because there is no good way to trust > the resolver if you don't create that trust relationship prior to resolving > an alias from it. > > I think that having to pre-trust the resolver would be an acceptable solution > to all.. Those whose policy requires a simpler process can get a 3rd party CA > list, much like the ones provided with web browsers and operating systems. > Those with strict verification policies can choose to pre verify every public > key.. and these processes are familiar to many organizations using PKI for > other things already. In a client, presenting the usual certificate detail > dialog, showing the public key, subject, issuer, and thumbprint would be > sufficient to allow users to implement their own policies without forcing it > one way or another. > > Please consider that while some organizations or users might require strong > anonymity and pre existing trust, there are others who may want to do the > opposite and that is just as valid, even if you or 'everyone else' disagrees > with that. In the case of bitcoin, it will be used as part of a larger > system, and whatever concerns are created by 'insecure' alias resolution may > well be addressed in another part of the system. The most successful > standards and implementations are the ones which provide the most flexibility > - primarily because that allows users to extend them in ways the original > designers didn't necessarily plan for. > > Thanks, > Laszlo > > > > On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote: > >> On 2011 December 19 Mo
Re: [Bitcoin-development] [BIP 15] Aliases
On Fri, Dec 16, 2011 at 1:52 PM, Khalahan 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=5678iop&anything_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 e
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins 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] Fwd: [BIP 15] Aliases
Agreed, I find measured dialog much more valuable. I also agree that standards take time and are messy, though choosing a standard allows additional participation and can drive interopability. One does not need to accept IBANN but we should participate in the dialog in its development. internet-drafts don't make it through the process unchanged. IBANN is a starting point not the end of the discussion. -rick On Fri, Dec 16, 2011 at 11:06 AM, Gavin Andresen wrote: > First: everybody please try to focus on the issues/ideas, and try to > avoid this becoming a flame war. > > Second: I think Walter Stanish made several good points that may have > been missed in all the long posts and discussion, the main one being: > > The banking industry has been dealing with many of these issues for > years; I think we should not dismiss their experience. > > I think there is also a huge public relations benefit to using a > standard like IIBAN instead of inventing our own. Having a Bitcoin > Payment Routing Address (or whatever it ends up being called) that > looks like the number issues by big financial institutions will give > people the warm fuzzies. > > I don't really care what happens behind the scenes, as long as it is > as secure as an HTTPS connection (RE: CA pwnage: there's no such > thing as perfect security, and until a more secure solution comes > along HTTPS is the best we've got). > > And I'll reiterate that there doesn't have to be just one solution. > > My only concern is that IIBAN is Yet Another Fledgling Standard, and > those little details that remain to be worked out could take years to > actually work out. > > -- > -- > Gavin Andresen > > -- > 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 -- 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] Fwd: [BIP 15] Aliases
Its a negative example -- in that the IETF does not specify anything in the PATH part of the URI. The scheme, sure, but not in the path, there are many types of URI schemes ( start with RFC 2396 ) There is significant upside to having your own scheme and having apps understand how to integrate with it. Frankly, having just one client (I understand there are more) is an artifact that hinders acceptance and participation. If you want to go the route of https then specifying a scheme is your path forward I still believe that it is experience that is leading this thread down the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is just what you are used to. Review the bitcoin protocol, there is an elegance there -- not found in the https schemes proposed thus far. CGI isn't a protocol, nor does it address usability/identity issues. Providing a mapping from u...@authority.tld addresses usability and identity. I'd like to see an elegant transformation, specifically I take to task anyone that advocates https://authority/foo/user?tx=1zhd789632uilos as elegant. -rick On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins wrote: > On 2011 December 16 Friday, Rick Wesson wrote: >> On Thu, Dec 15, 2011 at 4:07 PM, slush wrote: >> > I really like this proposal with standard URLs. All other proposals like >> > DNS mapping or email aliases converted to URLs with some weird logic >> > looks strange to me. >> >> wow, really. Maybe you could review some RFCs, there are thousands of >> examples where some really smart engineers chose the exact opposite >> path which you propose below. > > Could you point me at an example? > > > Andy > > -- > Dr Andy Parkins > andypark...@gmail.com -- 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 8:17 AM, Pieter Wuille wrote: > On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote: >> Hardening the protocols and usability are related. Please look at some >> of the work done in the IETF which has a long history in addressing >> many of the issues you are considering. Review some of the elegance in >> the bitcoin protocols. The proposals in this thread are neither clear >> nor elegant. If you can't reach nearly the same level of >> sophistication then I suggest you rethink your scheme. > > That's why you use URI + bitcoin address pairs, and use SSL communication > authenticated using the respective bitcoin pubkey. They may spoof your DNS > server, they can't fake having the requested corresponding private key. You are making my point (again) regarding usability and security. Aliases are not a https secured URI+bitcoin address. -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 12:35 AM, Pieter Wuille wrote: > On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote: >> I wrote this pre-draft: [snip] > > To conclude: my suggestion would be to use URLs as address identifiers, > optionally suffixed with a bitcoin address for authentication. > This means my "address" would be either "sipa.be/pw.btc" or > "sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://";) > is an implicit default. Initiating a payment to either of these would > result in a GET of https://sipa.be/pw.btc. When a transaction is > constructed, it is POSTed back to that URL. > > If we can agree on reasonable hardcoded mapping, p...@sipa.be could just > be a shorthand for either of these (though vulnerable to proofing...). I believe that any URI scheme will still leverage DNS and inherit any base issues you would have with TXT records. I suggest looking at DANE and reviewing their work on hardening certificate (x.509) infrastructure as your HTTPS scheme will inherit the issues we currently experience with CAs getting p0wned. Hardening the protocols and usability are related. Please look at some of the work done in the IETF which has a long history in addressing many of the issues you are considering. Review some of the elegance in the bitcoin protocols. The proposals in this thread are neither clear nor elegant. If you can't reach nearly the same level of sophistication then I suggest you rethink your scheme. -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] Fwd: [BIP 15] Aliases
On Thu, Dec 15, 2011 at 4:07 PM, slush wrote: > I really like this proposal with standard URLs. All other proposals like DNS > mapping or email aliases converted to URLs with some weird logic looks > strange to me. wow, really. Maybe you could review some RFCs, there are thousands of examples where some really smart engineers chose the exact opposite path which you propose below. -rick > Plain URLs (returning address in response body, redirecting to URI > "bitcoin:" or anything else) are very clear solution, easy to > implement in clients and very easy to understand by people. It's also > extremely flexible - almost everybody can somewhere setup static file > containing his "personal" addresses or it's very easy to integrate such > solution with eshops (providing custom address for given order) etc. I'm > definitely for this solution. > > Best, > slush > > On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins wrote: >> >> On 2011 December 13 Tuesday, Amir Taaki wrote: >> >> > Maybe I wasn't clear enough in the document, but this is the intent with >> > the HTTPS proposal. >> >> I don't like the idea of a hard-coded mapping at all. We shouldn't be >> making >> choices on behalf of server operators. It's up to them how they arrange >> their >> domain names and paths. >> >> I also agree that DNS is not the technology to use. DNS is a nightmare. >> >> > gen...@foo.org >> > >> > Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system >> > responds with a bitcoin address. Whether the system gives you a new >> > address from a pool of addresses, or contacts the merchant behind the >> > scenes is implementation defined. >> > >> > I'll clarify it later. This is the relevant line: >> > >> > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + >> > pszEncodedNick; >> > >> > Between HTTPS service and server service, I lean slightly towards HTTPS >> > (automatic encrypted connection, CAs + all benefits of DNS). But still >> > interested in arguments in favour of a server service (daemon answering >> > queries). >> >> Why bother with an encoding scheme at all? If the address >> >> gen...@foo.org >> >> always maps to >> >> https://foo.org/bitcoin-alias/?handle=genjix >> >> Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" >> and >> "?handle=" and the original email-looking "gen...@foo.org". Just use the >> URL. >> Then the author of the service can use whatever they want. >> >> "Can I pay you 10 BTC?" >> "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'" >> >> While I might implement my alias server like this: >> >> "Sure, send it to 'https://google.com/bitcoin/?andyparkins'" >> "Sure, send it to 'https://parkins.co.uk/"; >> >> ... or any other URL they want -- any of which suit might suit me and my >> webserver better than whatever mapping would otherwise be hard-coded. The >> world is already very familiar with URLs so this is no more scary than the >> email address. What's more, the email address form looks _too much_ like >> an >> email address, and will only lead to confusion ... "send it to >> gen...@foo.org" >> "so I use outlook express for that, right?" "erm, no, you put it in your >> bitcoin client". >> >> The URL form could easily be made to detect a browser connecting rather >> than a >> bitcoin client (and this is an area that would benefit from a standards >> document -- define the headers and user agent triggers that an alias >> server >> expects) and give them better instructions. >> >> https can be specified as the default, so "https://"; can be optional when >> they're typing. If, in the future, bitcoin gets a distributed >> peer-to-peer >> alias system, then a new URL type can be added easily >> "bcalias://andyparkins" >> might automatically find my node in the network and query it for an >> address >> (or whatever). >> >> All of the above is exactly why OpenID chose to use URLs for ID. >> >> >> >> Andy >> >> -- >> Dr Andy Parkins >> andypark...@gmail.com >> >> >> -- >> Systems Optimization Self Assessment >> Improve efficiency and utilization of IT resources. Drive out cost and >> improve service delivery. Take 5 minutes to use this Systems Optimization >> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > -- > 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 > ___
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
Are we designing protocols or applications, its easier and better for all involved if we design a protocol and then let the applications implement it. Lets stick to understanding how labels (dns) or URIs can be leveraged to securly obtain a bitcoin address, rather than reviewing capabilities of current applications. -rick On Wed, Dec 14, 2011 at 10:04 PM, Zell Faze wrote: > It is a lot easier to set up an HTTP server to dynamically respond with > addresses than a DNS record. It is considered a good practice to use a > different address for every payment. > > > "It stopped being just a website a long time ago. For many of us, most of > us, Wikipedia has become an indispensable part of our daily lives." > — Jimmy Wales, *Founder of Wikipedia* > <http://2e740a1a.qvvo.com/> > > Help protect it now. Please make a donation today: > http://www.wikimediafoundation.org/wiki/Donate > > > --- On *Wed, 12/14/11, Kyle Henderson * wrote: > > > From: Kyle Henderson > > Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases > To: "Zell Faze" > Cc: "Luke-Jr" , "Rick Wesson" < > r...@support-intelligence.com>, bitcoin-development@lists.sourceforge.net > Date: Wednesday, December 14, 2011, 11:56 PM > > > Just so we're clear, what is the need for HTTP at all? > > A query for a string and an answer can all be handled via DNS. > > On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze > http://mc/compose?to=zellf...@yahoo.com> > > wrote: > > Could we combine this proposal and the HTTPS proposal? > > The DNSSEC TXT record could give instructions on how to query an HTTPS > server to get the address. Then we get the dynamism of HTTPS without > having a rigid URL scheme for querying the server along with the advantages > of DNSSEC. > > > -- 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
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 : > 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.. > > 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] 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.. 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 : > 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.53&green_address=r > bitcoin://rest_of_url?amount=10.53&green_address=r&green_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] 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 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
Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
On Wed, Aug 24, 2011 at 10:19 AM, Gregory Maxwell wrote: > On Wed, Aug 24, 2011 at 1:07 PM, Rick Wesson > wrote: > > On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell > wrote: > >> On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr wrote: > >> > >> > - Replace hard limits (like 1 MB maximum block size) with something > that > >> > can > >> > dynamically adapt with the times. Maybe based on difficulty so it > can't > >> > be > >> > gamed? > >> Too early for that. > > Could you provide a reference to why in your estimation it is "to early." > > Simpy stating this as fact isn't enough to sway demand. > > Can you provide a reference to this 'demand' a post by Luke isn't > enough to support the claim of demand. > > how about trend, its a hard limit and as you acknowledged below we are not there yet; however the trend is for more transactions and we will bump into the limit. Being good architects we should consider how to scale or explicitly state why its a good idea not to. -rick > We're not at maximum size right now (thankfully). > > We don't know what the network dynamics would look like at that > traffic level. So how could we competently say what the right metrics > would be to get the right behavior there? Thats what I meant by too > early. > no one ever "knows" what the network dynamics are going to be in developing infrastructure -- so lets not kid our selves, in being able to estimate this before the code is even written. -rick -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell wrote: > On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr wrote: > > > - Replace hard limits (like 1 MB maximum block size) with something that > can > > dynamically adapt with the times. Maybe based on difficulty so it can't > be > > gamed? > > Too early for that. > > Could you provide a reference to why in your estimation it is "to early." Simpy stating this as fact isn't enough to sway demand. > - Adjust difficulty every block, without limits, based on a N-block > sliding > > window. I think this would solve the issue when the hashrate drops > > overnight, but maybe also add a block time limit, or perhaps include the > > "current block" in the difficulty calculation? > > The quantized scheme limits the amount of difficulty skew miners can > create by lying about timestamps to about a half a percent. A rolling > window with the same time constant would allow much more skew. > > > Replacing the "Satoshi" 64-bit integers with > > "Satoshi" variable-size fractions (ie, infinite numerator + denominator) > > Increasing precision I would agree with but, sadly, causing people to > need more than 64 bit would create a lot of bugs. > > how about we agree that increasing precision is a goal and worry about how to encode that once its on the road map. > infinite numerator + denominator is absolutely completely and totally > batshit insane. For one, it has weird consequences that the same value > can have redundant encodings. > > Most importantly, it suffers factor inflation: If you spend inputs > 1/977 1/983 1/991 1/997 the smallest denominator you can use for the > output 948892238557. > > Not to mention that the idiots writing financial software can only > barely manage to not use radix-2 floating point on everything. Asking > them to use arbitrary rational numbers with mixed radix will never > fly. > > > - Remove the 100 confirmation requirement for spending generated coins. > If > > they are respent before 100 confirmations, clients can/should flag the > new > > outputs as also "generated" or "recently generated" so recipients are > aware > > of the risk. > > Please lets not make bitcoin _less_ trustworthy. > > The 100 block maturity on generated coins is good. The generation from > an orphaning is lost forever like the losing side of a double spend, > but far far worse... because orphaning happens all the time on its own > without any malice. > > I agree it's obnoxious that you can't pad your generation payouts > without creating more transactions, but I don't see a solution for > that. Repeat the addresses... make up for it by increasing your payout > threshold. > > > -- > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
On Wed, Aug 24, 2011 at 8:45 AM, Gregory Maxwell wrote: > On Wed, Aug 24, 2011 at 11:12 AM, Gavin Andresen > wrote: > > It seems to me the fastest path to very secure, very-hard-to-lose > > bitcoin wallets is multi-signature transactions. > > > > To organize this discussion: first, does everybody agree? > > It's a good tool which we should have in our tool-belt. > > Though it's a bit of when you are a hammer all problems are nails. > This issue can also be addressed by things like external private key > protectors. But someone would have to build one. > > Someone might be more inclined to build such a thing if the software > had good support for tracking public keys without private keys, and > generating unsigned transactions for export to the device for signing. > > > ByteCoin pointed to a research paper that gives a scheme for splitting > > a private key between two people, neither of which every knows the > [snip] > > So I'm assuming that is NOT the fastest way to solving the problem. > > Regardless, it might be useful to contact the authors. > > > I still think it is a good idea to enable a set of new 'standard' > > multisignature transactions, so they get relayed and included into > > blocks. I don't want to let "the perfect become the enemy of the > > good" -- does anybody disagree? > > I agree. > > > The arguments against are that if the proposed standard transactions > > are accepted, then the next step is to define a new kind of bitcoin > > address that lets coins be deposited into a multisignature-protected > > wallet. > > > > And those new as-yet-undefined bitcoin addresses will have to be 2 or > > 3 times as big as current bitcoin addresses, and will be incompatible > > with old clients. > > > > So, if we are going to have new releases that are incompatible with > > old clients why not do things right in the first place, implement or > > enable opcodes so the new bitcoin addresses can be small, and schedule > > a block chain split for N months from now. > > One way of doing this would be to have an address which hashes an > ordered concatenation of many addresses (perhaps plus a length > argument). To redeem you provide the public keys which are signing, > plus the addresses which aren't signing, and the receiver validates. > > If it can be done, then yes, I agree it would be worth forking the chain. > > This _feels_ like something which could and should be done with the > existing (but disabled opcodes). > > > It's not exclusive, however, with a long N-address address type for > multisig destinations. We could support that _now_ and defer the > 'compressed version' until after people have experience with this > usage. The only cost would be supporting this address type forever, > which isn't that bad. > > It's also important to note that incompatibility wouldn't be complete: > The only limit is that old clients couldn't send funds to escrow > addresses— which is an issue no matter how you encode the information. > > > -- > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
wow, with all the feature requests and bug fixing that needs to be done you want to go off on a tangent. Vision my friend, once centered on robust architecture, may then be directed on a hard left turn. Lets get a feature road map done, bug fix and testing framework set up ... or fork this puppy to folks that can execute the above. -rick On Wed, Aug 24, 2011 at 8:12 AM, Gavin Andresen wrote: > It seems to me the fastest path to very secure, very-hard-to-lose > bitcoin wallets is multi-signature transactions. > > To organize this discussion: first, does everybody agree? > > ByteCoin pointed to a research paper that gives a scheme for splitting > a private key between two people, neither of which every knows the > full key, but, together, both can DSA-sign transactions. That's very > cool, but it involves high-end cutting-edge crypto like zero-knowledge > proofs that I know very little about (are implementations available? > are they patented? have they been thoroughly vetted/tested? etc). > So I'm assuming that is NOT the fastest way to solving the problem. > > If anybody has some open-source, patent-free, thoroughly-tested code > that already does DSA-key-splitting, speak up please. > > > I've been trying to get consensus on low-level 'standard' transactions > for transactions that must be signed by 2 or 3 keys; current draft > proposal is here: > https://gist.github.com/39158239e36f6af69d6f > and discussion on the forums here: > https://bitcointalk.org/index.php?topic=38928.0 > ... and there is a pull request that is relevant here: > https://github.com/bitcoin/bitcoin/pull/319 > > > I still think it is a good idea to enable a set of new 'standard' > multisignature transactions, so they get relayed and included into > blocks. I don't want to let "the perfect become the enemy of the > good" -- does anybody disagree? > > The arguments against are that if the proposed standard transactions > are accepted, then the next step is to define a new kind of bitcoin > address that lets coins be deposited into a multisignature-protected > wallet. > > And those new as-yet-undefined bitcoin addresses will have to be 2 or > 3 times as big as current bitcoin addresses, and will be incompatible > with old clients. > > So, if we are going to have new releases that are incompatible with > old clients why not do things right in the first place, implement or > enable opcodes so the new bitcoin addresses can be small, and schedule > a block chain split for N months from now. > > My biggest worry is we'll say "Sure, it'll only take a couple days to > agree on how to do it right" and six months from now there is still no > consensus on exactly which digest function should be used, or whether > or not there should be a new opcode for arbitrary boolean expressions > involving keypairs. And people's wallets continue to get lost or > stolen. > > > > -- > -- > Gavin Andresen > > > -- > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
