Nostr notes by

📅 Original date posted:2012-11-27 📝 Original message:> ...

2023-06-07T10:40:41Z

In reply to nevent1q…5tuz
_________________________

📅 Original date posted:2012-11-27
📝 Original message:>
> 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

📅 Original date posted:2012-11-27 📝 Original message:On ...

2023-06-07T10:40:35Z

In reply to nevent1q…nhnl
_________________________

📅 Original date posted:2012-11-27
📝 Original message:On Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish <walter at 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

📅 Original date posted:2012-11-26 📝 Original message:On ...

2023-06-07T10:40:22Z

In reply to nevent1q…2gqk
_________________________

📅 Original date posted:2012-11-26
📝 Original message:On Mon, Nov 26, 2012 at 4:31 PM, Luke-Jr <luke at dashjr.org> 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

📅 Original date posted:2012-11-26 📝 Original message:I hope ...

2023-06-07T10:40:16Z

In reply to nevent1q…8rac
_________________________

📅 Original date posted:2012-11-26
📝 Original message: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 <jgarzik at exmulti.com> wrote:
> On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen <gavinandresen at gmail.com> 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.
> jgarzik at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2012-11-26 📝 Original message:X.509 ...

2023-06-07T10:40:09Z

In reply to nevent1q…0hac
_________________________

📅 Original date posted:2012-11-26
📝 Original message: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 <gavinandresen at gmail.com> 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.00000001 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) string from the first x509chain
> certificate and ask the customer if they would like to submit payment
>
> Payment
> -------
>
> ::
>
> message Payment {
> required Invoice invoice = 1;
> repeated bytes transactions = 2;
> repeated Output refund_to = 3;
> optional string memo = 4;
> }
>
> invoice : the invoice received from the merchant. A merchant must
> validate the Invoice and may reject the Payment if the Invoice was
> altered by the customer.
>
> transactions : One or more valid, signed Bitcoin transactions that
> fully pay the Invoice
>
> refund_to : One or more outputs where the merchant may return funds,
> if necessary.
>
> memo : UTF-8 encoded, plain-text note from the customer to the merchant.
>
> If the customer authorizes payment, then the Bitcoin client:
>
> 1. Creates and signs a transaction with one output sending the Invoice.script
> 2. If there is no Invoice.receiptURI, then the transaction is
> broadcast on the Bitcoin p2p network.
> 3. Else POST a Payment message to Invoice.receiptURI and expect a
> SignedReceipt in response.
>
> Invoice.receiptURI must be secure against man-in-the-middle attacks
> that might alter Payment.refund_to.
>
> *Note: an alternative would be a SignedPayment message that ties the
> signatures in Payment.transactions to a signature for the entire
> Payment message. Spending multisig inputs that may be controlled by
> more than one person or spending arbitrary non-standard transactions
> makes that non-trivial.*
>
> Receipt/SignedReceipt
> ---------------------
>
> ::
>
> message Receipt {
> required Payment payment = 1;
> required bool accepted = 2;
> optional string memo = 3;
> }
>
> accepted : true if the Payment is accepted and will be broadcast on
> the Bitcoin p2p network.
>
> memo : UTF-8 encoded note that should be displayed to the customer
> indicating that the transaction is complete.
>
> ::
>
> message SignedReceipt {
> required Receipt receipt = 1;
> required bytes signature = 3;
> }
>
> A SignedReceipt is a Receipt signed using the private key
> corresponding to the public key in the first certificate in the
> Receipt->Payment->Invoice.x509chain and the HMAC SHA-256 algorithm.
>
> Upon receiving a SignedReceipt, a Bitcoin client should validate the
> signature and, if valid, display the Receipt.memo and store the
> SignedReceipt as proof-of-payment.
>
> If a SignedReceipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in the transaction to the customer's wallet.
>
>
> Certificates
> ============
>
> The Invoice.x509chain (X.509 Certificate Chain) field contains the
> X.509 public key certificate or certificate chain [RFC5280]
> corresponding to the key used to digitally sign the Invoice and
> Receipt. The certificate or certificate chain is represented as an
> array of DER [ITU.X690.1994] PKIX certificate value. The certificate
> containing the public key of the entity that digitally signed the
> Invoice MUST be the first certificate. This MAY be followed by
> additional certificates, with each subsequent certificate being the
> one used to certify the previous one. The recipient MUST verify the
> certificate chain according to [RFC5280] and reject the payment
> request if any validation failure occurs.
>
> *What should we say about root certificates and certificate management
> in general? Any requirements, or leave it up to each Bitcoin client to
> determine which root CA's are trustworthy, as happens with web
> browsers? Gavin suggests trusting only (say) ten of the Extended
> Validation authorities:
> http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification
> *
>
> *X.509 is widely criticised for doing too much. However, it is the
> Public Key Infrastructure (PKI) system we're stuck with. Do web
> browsers / certificate authorities support the full X.509 spec, or
> only a subset? Should Bitcoin clients only support some well-defined
> subset of X.509 ? More research needed here... *
>
> Use Cases
> =========
>
> Merchant Payment Service
> ------------------------
>
> A merchant payment service (like Paysius or bit-pay.com) would use
> Invoices and Receipts as follows:
>
> 1. Merchant pays for a certificate from a certificate authority, and
> then gives the payment service the certificate and their private key.
> This could be the same certificate and private key as is used for the
> merchant's web site, but best security practice would be to purchase a
> separate certificate for authenticating Invoices. Very successful
> merchant payment services might act as intermediate certificate
> authorities, issuing certificates for their merchants.
> 2. Customer goes through the checkout process on either the merchant's
> or payment service's web site.
> 3. At the end of the checkout process, a SignedInvoice is generated
> and sent to the customer's Bitcoin client.
> 4. Customer's Bitcoin client displays the Invoice, showing that the
> payment is for the merchant.
> 5. On customer approval, a Payment is sent to the payment service's
> paymentURI. The merchant is notified of the payment, and the customer
> receives a SignedReceipt as proof-of-payment.
>
> SatoshiDice
> -----------
>
> SatoshiDice (www.satoshidice.com) is an extremely popular game that
> uses tiny transactions for some customer/service communications. In
> particular, customers can add an extra output to their transactions to
> indicate where winnings should be sent. And SatoshiDice creates tiny
> transactions to let their customers know that a bet was received, but
> lost.
>
> Assuming Bitcoin clients upgrade to support this proposal, a bet on
> SatoshiDice would proceed as follows:
>
> 1. Customer clicks on a link on SatoshiDice.com and their Bitcoin
> client receives a SignedInvoice.
> 2. Customer authorizes payment, and their Bitcoin client creates a
> Payment message and submits it directly to
> https://satoshidice.com/something
> 3. The SatoshiDice web server checks to make sure the transaction is
> valid, broadcasts it, and determines whether the customer wins or
> loses. It returns a SignedReceipt with either a "You win" or "You
> lost" memo.
> 4. If the customer won, it broadcasts a transaction to pay them using
> Payment.refund_to
> 5. Customer's Bitcoin client displays the win/lose memo, and if they
> won the winnings appear in their wallet when received over the p2p
> network.
>
> Multiperson Wallet
> ------------------
>
> This use case starts with a multi-signature Bitcoin address or wallet,
> with keys held by two different people (Alice and Bob). Payments from
> that address/wallet must be authorized by both Alice and Bob, and both
> are running multi-signature-capable Bitcoin clients.
>
> Alice begins the payment process by getting a SignedInvoice from a
> merchant that needs to be paid. She authorizes payment and her Bitcoin
> client creates a Payment message with a partially-signed transaction,
> which is then sent to Bob any way that is convenient (email
> attachment, smoke signals...).
>
> Bob's Bitcoin client validates the SignedInvoice and asks Bob to
> authorize the transaction. He says OK, his Bitcoin client completes
> the transaction by providing his signature, submits the payment to the
> merchant, and then sends a message to Alice with the SignedReceipt he
> received from the merchant, completing the payment process.
>
>
> Design Notes
> ============
>
> Why X.509 Certificates?
> -----------------------
>
> This proposal uses X.509 certificates as the identity system for
> merchants because most of them will have already purchased a
> certificate to secure their website and will be familiar with the
> process of proving their identity to a certificate issuing authority.
>
> Implementing a better global PKI is outside the scope of this
> proposal. If a better PKI is adopted, the only change to this proposal
> would be to replace the Invoice.x509chain with whatever that better
> infrastructure uses to identify entities.
>
>
> Why not JSON?
> -------------
>
> Invoice, Payment and Receipt messages could all be JSON-encoded. And
> the Javascript Object Signing and Encryption (JOSE) working group at
> the IETF has a draft specification for signing JSON data.
>
> But the spec is non-trivial. Signing JSON data is troublesome because
> JSON can encode the same data in multiple ways (whitespace is
> insignificant, characters in strings can be represented escaped or
> un-escaped, etc.), and the standards committee identified at least one
> security-related issue that will require special JSON parsers for
> handling JSON-Web-Signed (JWS) data (duplicate keys must be rejected
> by the parser, which is more strict than the JSON spec requires).
>
> A binary message format has none of those complicating issues. Which
> encoding format to pick is largely a matter of taste, but Protocol
> Buffers is a simple, robust, multi-programming-language,
> well-documented, easy-to-work-with, extensible format.
>
> What about a merchant-pays-fee feature?
> ---------------------------------------
>
> It is desireable to allow a merchant to pay the cost of any Bitcoin
> network transaction processing fees, so if a customer is paying for a
> 1 BTC item they pay exactly 1 BTC.
>
> One way of accomplishing that is to add a 'maxfee' field to the
> Invoice, and have the Bitcoin client construct a transaction that pays
> the merchant (amount-maxfee).
>
> Another way of accomplishing that is to change the transaction
> selection code used by Bitcoin miners, so that dependent transactions
> are considered as a group. Then a merchant with several unconfirmed
> zero-fee transaction from customers can create a pay-to-self
> transaction with a large enough fee to pay for the set of transactions
> to be confirmed.
>
> A third way of accomplishing that is for the Bitcoin client to sign
> Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag, and for
> the merchant to add an additional, small-BTC-value input to the
> transaction before broadcasting it. That additional input would go
> directly to miners as a fee. *Note: Gavin is not sure if he loves or
> hates this idea.*
>
> Checking for revoked certificates
> ---------------------------------
>
> The Online Certificate Checking Protocol (OCSP) is supposed to be a
> quick and easy way for applications to check for revoked certificates.
>
> In practice, it doesn't work very well. Certificate Authorities have
> no financial incentive to support a robust infrastructure that can
> handle millions of OCSP validation requests quickly.
>
> Ideally, Bitcoin clients would use OCSP to check certificate statuses
> every time they received or re-used an Invoice. But if that results in
> long pauses or lots of false-positive rejections (because an OCSP
> endpoint is offline or overwhelmed, perhaps) then merchants and
> customers might revert to just using "never fails" Bitcoin addresses.
>
>
>
> References
> ==========
>
> Public-Key Infrastructure (X.509) working group :
> http://datatracker.ietf.org/wg/pkix/charter/
>
> RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate
> Status Protocol - OCSP : http://tools.ietf.org/html/rfc2560
>
> Protocol Buffers : https://developers.google.com/protocol-buffers/
>
> See Also
> ========
>
> Javascript Object Signing and Encryption working group :
> http://datatracker.ietf.org/wg/jose/
>
> sipa's payment protocol proposal: https://gist.github.com/1237788
>
> ThomasV's "Signed Aliases" proposal : http://ecdsa.org/bitcoin_URIs.html
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2012-11-26 📝 Original message:On ...

2023-06-07T10:39:56Z

In reply to nevent1q…j9eq
_________________________

📅 Original date posted:2012-11-26
📝 Original message:On Mon, Nov 26, 2012 at 4:26 PM, Mike Hearn <mike at plan99.net> 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

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T02:48:16Z

In reply to nevent1q…9nm3
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: A discussion about the use of HTTP(s) transport for a look-up in the PATH portion of the URI and the need for standardization in the development process.
📝 Original message:On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins <andyparkins at gmail.com> wrote:

[snip]

>
> You've been unfair, the equivalent of your "user at 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
> "user at 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

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T02:48:07Z

In reply to nevent1q…yu66
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Participants discuss the benefits of using a standard like IIBAN for Bitcoin Payment Routing Address, which can drive interoperability and provide public relations benefits.
📝 Original message: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
<gavinandresen at gmail.com> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T02:47:57Z

In reply to nevent1q…f3qg
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: The IETF does not specify anything in the PATH part of the URI, but having your own scheme and having apps understand how to integrate with it has significant upside. The use of CGI and HTTP requests is not magic, it is just what people are used to. Providing a mapping from user at authority.tld addresses usability and identity.
📝 Original message: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 user at 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 <andyparkins at gmail.com> wrote:
> On 2011 December 16 Friday, Rick Wesson wrote:
>> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush at centrum.cz> 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
> andyparkins at gmail.com

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T02:47:48Z

In reply to nevent1q…ptz3
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Slush prefers standard URLs for Bitcoin addresses, finding other proposals like DNS mapping or email aliases converted to URLs strange.
📝 Original message:On Thu, Dec 15, 2011 at 4:07 PM, slush <slush at centrum.cz> 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:<address>" 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 <andyparkins at gmail.com> 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.
>>
>> > genjix at 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
>>
>> genjix at 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 "genjix at 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
>> genjix at 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
>> andyparkins at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2011-12-15 🗒️ Summary of this ...

2023-06-07T02:47:41Z

In reply to nevent1q…qtdw
_________________________

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Designing a protocol is better than designing applications; focus on using labels or URIs to securely obtain a bitcoin address.
📝 Original message: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 <zellfaze at yahoo.com> 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 <k at old.school.nz>* wrote:
>
>
> From: Kyle Henderson <k at old.school.nz>
>
> Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> To: "Zell Faze" <zellfaze at yahoo.com>
> Cc: "Luke-Jr" <luke at dashjr.org>, "Rick Wesson" <
> rick at support-intelligence.com>, bitcoin-development at 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 <zellfaze at yahoo.com<http://mc/compose?to=zellfaze@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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111215/28f5a961/attachment.html>;

📅 Original date posted:2011-12-15 🗒️ Summary of this ...

2023-06-07T02:47:38Z

In reply to nevent1q…6kd0
_________________________

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Proposal to use IANA for mapping IIBANs to bitcoin addresses instead of relying on a single authorized institution.
📝 Original message:> 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

📅 Original date posted:2011-12-14 🗒️ Summary of this ...

2023-06-07T02:46:53Z

In reply to nevent1q…0jfa
_________________________

📅 Original date posted:2011-12-14
🗒️ Summary of this message: Using secured zones to publish TXT records for digital currencies is a good practice, but not everyone will adhere to it. Sticking to standard practices is important.
📝 Original message: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 <luke at 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.

📅 Original date posted:2011-12-14 🗒️ Summary of this ...

2023-06-07T02:46:47Z

In reply to nevent1q…tyfg
_________________________

📅 Original date posted:2011-12-14
🗒️ Summary of this message: DNSSEC is an internet standard widely deployed in the root, TLDs, ccTLDs, and second-level domains. TXT records can be used for digital currencies.
📝 Original message: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
rick at 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.elviejo at 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.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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T02:45:23Z

In reply to nevent1q…4yjv
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Rick Wesson suggests that hardening protocols and usability are related, and recommends looking at IETF's work and the elegance of Bitcoin protocols. He argues that aliases are not as secure as HTTPS secured URI+Bitcoin address pairs.
📝 Original message:On Fri, Dec 16, 2011 at 8:17 AM, Pieter Wuille <pieter.wuille at gmail.com> 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

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T02:45:17Z

In reply to nevent1q…8dsu
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: A proposal to use URLs as address identifiers, optionally suffixed with a bitcoin address for authentication, is suggested. Hardening protocols and usability are related.
📝 Original message:On Fri, Dec 16, 2011 at 12:35 AM, Pieter Wuille <pieter.wuille at gmail.com> 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, pw at 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

📅 Original date posted:2011-12-19 🗒️ Summary of this ...

2023-06-07T02:44:26Z

In reply to nevent1q…zrl2
_________________________

📅 Original date posted:2011-12-19
🗒️ Summary of this message: DANE uses secure DNS to associate TLS server's certificate with the intended domain name, mitigating the need for CAs and allowing self-signed certificates.
📝 Original message: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 user at 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 <solar at heliacal.net> 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 Monday, Jorge Timón wrote:
>>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>>> know the HTTPS possible attack, but maybe it needs a warning message
>>> too, from what you people are saying. Although using namecoin to
>>
>> The problems with HTTPS have been social rather than technical. Multiple CAs
>> have been strong-armed by governments or tricked into issuing fake
>> certificates by scammers. There is no technical measure around that. By
>> using the CA certificate we are saying to the system "here is someone I trust
>> to issue a certificate". So far, with a large number of CAs, that trust is
>> misplaced.
>>
>> I'm of the opinion though that this problem is outside the remit of bitcoin to
>> solve.
>>
>> Perhaps we should be more strict about which CA certificates are trusted by
>> the bitcoin client: say restrict it to those who have demonstrably good
>> practices for verifying identity; rather than the ridiculous amount of trust
>> that comes pre-installed for me in my browser.
>>
>>
>>
>> Andy
>>
>> --
>> Dr Andy Parkins
>> andyparkins at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T02:43:48Z

In reply to nevent1q…2c4j
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Various proposals for linking Bitcoin addresses to domain names or aliases have limitations, including centralization, reliance on HTTPS and CA, and DNSSEC requirements. Namecoin is a potential solution.
📝 Original message:On Fri, Dec 16, 2011 at 1:52 PM, Khalahan <khal at 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=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 event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2011-08-24 🗒️ Summary of this ...

2023-06-07T02:18:03Z

In reply to nevent1q…608j
_________________________

📅 Original date posted:2011-08-24
🗒️ Summary of this message: A discussion on the Bitcoin-development mailing list about potential changes to the Bitcoin protocol, including dynamically adapting block size and adjusting difficulty every block.
📝 Original message:On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <luke at dashjr.org> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/995254b5/attachment.html>;

📅 Original date posted:2011-08-24 🗒️ Summary of this ...

2023-06-07T02:17:47Z

In reply to nevent1q…lu52
_________________________

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Discussion on the use of multi-signature transactions for secure Bitcoin wallets, including the possibility of new Bitcoin addresses and opcodes.
📝 Original message:On Wed, Aug 24, 2011 at 8:45 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Wed, Aug 24, 2011 at 11:12 AM, Gavin Andresen
> <gavinandresen at gmail.com> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/4805602a/attachment.html>;

📅 Original date posted:2011-08-24 🗒️ Summary of this ...

2023-06-07T02:17:41Z

In reply to nevent1q…0taf
_________________________

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Discussion on implementing multi-signature transactions for more secure Bitcoin wallets. Proposal for new 'standard' transactions and potential compatibility issues.
📝 Original message: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 <gavinandresen at gmail.com>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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/887027f8/attachment.html>;

📅 Original date posted:2011-08-03 🗒️ Summary of this ...

2023-06-07T02:10:57Z

In reply to nevent1q…j77f
_________________________

📅 Original date posted:2011-08-03
🗒️ Summary of this message: Discussion on creating a custom DNS server to find long-lived peers running the latest version of Bitcoin to improve peer bringup for Android apps.
📝 Original message:Starting from bitcoinj, I have plenty of ways to publish DNS. Why sort them
by version? Ordering from highest to lowest?

how about publishing addresses under version.example.com if you version has
a perfrence?

-rick

On Wed, Aug 3, 2011 at 7:10 AM, Mike Hearn <mike at plan99.net> wrote:

> There's no project currently :-)
>
> Starting from Matts code is probably the way to go. It's written in PHP.
> Alternatively, you could write a Java app for it, as there are drop-in DNS
> serving libraries you could link with BitCoinJ+sqlite. It probably wouldn't
> be that hard. You'd want to sort nodes by version, how long they've been
> observed to exist, the last polling time, etc.
>
> On Wed, Aug 3, 2011 at 4:00 PM, Rick Wesson <rick at support-intelligence.com
> > wrote:
>
>> Mike,
>>
>> I think I can contribute to your DNS seeding project. Could you help
>> define long-lived peers?
>>
>> -rick
>>
>>
>> On Wed, Aug 3, 2011 at 3:04 AM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> This is expected to happen from time to time of course as it's inherently
>>> racy, but there are a *lot* of bad nodes appearing in the DNS seeds.
>>>
>>> $ nmap -oG /tmp/x -p 8333 `dig +short bitseed.bitcoin.org.uk
>>> dnsseed.bluematt.me bitseed.xf2.org`
>>> ...
>>> Nmap done: 48 IP addresses (25 hosts up) scanned in 9.80 seconds
>>>
>>> $ grep -c 'closed' /tmp/x
>>> 6
>>>
>>> So of 48 IPs returned only 19 are actually usable. This is slowing down
>>> peer bringup for the Android apps, which don't currently save the addresses
>>> of last-used peers (yes, I know we should fix this).
>>>
>>> I was talking to a friend a few days ago about Bitcoin, he seemed
>>> interested. I'm hoping he might take on DNS seeding as a project. A custom
>>> DNS server that watches the network to find long-lived peers that run the
>>> latest version would be helpful for resolving this kind of thing.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>>> The must-attend event for mobile developers. Connect with experts.
>>> Get tools for creating Super Apps. See the latest technologies.
>>> Sessions, hands-on labs, demos & much more. Register early & save!
>>> http://p.sf.net/sfu/rim-blackberry-1
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110803/1aaa914c/attachment.html>;

📅 Original date posted:2011-08-03 🗒️ Summary of this ...

2023-06-07T02:10:50Z

In reply to nevent1q…ejer
_________________________

📅 Original date posted:2011-08-03
🗒️ Summary of this message: Mike is experiencing issues with bad nodes appearing in DNS seeds, slowing down peer bringup. He hopes a custom DNS server can resolve this.
📝 Original message:Mike,

I think I can contribute to your DNS seeding project. Could you help define
long-lived peers?

-rick

On Wed, Aug 3, 2011 at 3:04 AM, Mike Hearn <mike at plan99.net> wrote:

> This is expected to happen from time to time of course as it's inherently
> racy, but there are a *lot* of bad nodes appearing in the DNS seeds.
>
> $ nmap -oG /tmp/x -p 8333 `dig +short bitseed.bitcoin.org.uk
> dnsseed.bluematt.me bitseed.xf2.org`
> ...
> Nmap done: 48 IP addresses (25 hosts up) scanned in 9.80 seconds
>
> $ grep -c 'closed' /tmp/x
> 6
>
> So of 48 IPs returned only 19 are actually usable. This is slowing down
> peer bringup for the Android apps, which don't currently save the addresses
> of last-used peers (yes, I know we should fix this).
>
> I was talking to a friend a few days ago about Bitcoin, he seemed
> interested. I'm hoping he might take on DNS seeding as a project. A custom
> DNS server that watches the network to find long-lived peers that run the
> latest version would be helpful for resolving this kind of thing.
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110803/05aea1f2/attachment.html>;

📅 Original date posted:2011-07-27 🗒️ Summary of this ...

2023-06-07T02:08:35Z

In reply to nevent1q…cztf
_________________________

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Offering a bounty for a technical lead to improve software functionality could increase Bitcoin's value, rather than offering bounties for bug fixes.
📝 Original message:personally, if the software works better (less bugs) then btc will be more
valuable. offering bounty is orthorginal to finding the right technical lead
that will hurd the effort.

put a bounty (salary) on the person to lead the effort, not the bugs

-rick

On Wed, Jul 27, 2011 at 7:28 AM, Luke-Jr <luke at dashjr.org> wrote:

> On Wednesday, July 27, 2011 10:20:07 AM John Smith wrote:
> > On Wed, Jul 27, 2011 at 11:14 AM, Joel Joonatan Kaartinen
> > <joel.kaartinen at gmail.com> wrote:
> > > Perhaps even add a way for anyone add to the bounty attached to a bug
> on
> > > the bug tracker? Also, a listing page for bugs with their bounties
> might
> > > be nice too.
> >
> > Good idea. I'm not sure if the github bug tracker supports extension
> > attributes, but it'd be a great place to add it. Also, people can let
> know
> > that they're already working on a feature using a comment, to prevent
> > double work.
>
> I'm not sure a few small bounties would justify agreeing to GitHub's steep
> demand for potentially unlimited money in their terms of service...
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110727/3b860209/attachment.html>;