Rick Wesson [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-07-26 to 2013-12-10
💬 Posted a total of 36 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925u

Profile Code

nprofile1qqsrprsdrma3wpavdwfv6zcecvzgs2eer86t6kfnd398rrq4n0w0vwcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsxq5c7k

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925u

Show more details

Last Notes

2023-06-07 17:10:37

- reply

📅 Original date posted:2013-12-10
📝 Original message:+1
On Mon, Dec 9, 2013 at 2:06 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> On Tue, Dec 10, 2013 at 8:01 AM, Ryan Carboni <ryan.jc.pc at gmail.com>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 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/20131209/229d288d/attachment.html>

2023-06-07 17:05:29

- reply

📅 Original date posted:2013-08-02
📝 Original message: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 <aaxiomfinity at gmail.com> wrote:
> wonder if it would be good idea to have a alias to wallet id nameserver in
> the client software where a person can use a english name to describe a
> wallet public key address? and the software can use it to look up the
> wallet id.
>
> wallet ids are hard to remember/recall.
>
> -chris
> http://tawhakisoft.com/
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20130802/9bdd2349/attachment.html>

2023-06-07 13:31:36

- reply

📅 Original date posted:2013-02-11
📝 Original message:I prefer to leverage the signing of the (.) root in the DNS tree. The
amount of effort in signing the root holds more weight than building a CA
off the bitcoin blockchain.
If you want to associate identifiers for payment addresses I suggest
putting those in DNSSEC signed records in the DNS.
For routing around x.509 CAs I suggest participating in the DANE working
group in the IETF.
-rick
On Fri, Feb 8, 2013 at 2:03 AM, Timo Hanke <timo.hanke at web.de> wrote:
> There have been proposals to use the blockchain to establish
> "identities". firstbits is a simple example. I would like to announce a
> project that extends this idea to turn the blockchain into a "root CA"
> that can sign arbitrary certificates. The purpose is to use these
> certificates in the payment protocol, where some might consider
> traditional centralized root CAs unsatisfactory.
>
> Code is here: https://github.com/bcpki
>
> Technical specification and full-length examples are found in the wiki.
> I therefore spare myself from repeating the details here, even though,
> of course, discussion about those details is welcome on this list.
>
> Excerpt from README.md follows:
>
> First, we have drafted a quite general specification for bitcoin
> certificates (protobuf messages) that allow for a variety of payment
> protocols (e.g. static as well as customer-side-generated payment
> addresses).
> This part has surely been done elsewhere as well and is orthogonal to the
> goal of this project.
> What is new here is the signatures _under_ the certificates.
>
> We have patched the bitcoind to handle certificates, submit signatures to
> the blockchain, verify certificates against the blockchain, pay directly to
> certificates (with various payment methods), revoke certificates.
> Signatures in the blockchain are stored entirely in the UTXO set (i.e. the
> unspend, unprunable outputs).
> This seems to make signature lookup and verification reasonably fast:
> it took us 10s in the mainnet test we performed (lookup is instant on the
> testnet, of course).
>
> Payment methods include: static bitcoin addresses, client-side derived
> payment addresses (pay-to-contract), pay-to-contract with multisig
> destinations (P2SH)
>
> Full-length real-world examples for all payment methods are provided in
> the tutorial pages.
> These examples have actually been carried out on testnet3.
>
> For further details and specifications see the wiki.
>
> timo hanke
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development 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/20130211/079342ad/attachment.html>

2023-06-07 12:40:41

- reply

📅 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

2023-06-07 12:40:35

- reply

📅 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

2023-06-07 12:40:22

- reply

📅 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

2023-06-07 12:40:16

- reply

📅 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

2023-06-07 12:40:09

- reply

📅 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

2023-06-07 12:39:56

- reply

📅 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

2023-06-07 04:48:16

- reply

📅 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

2023-06-07 04:48:07

- reply

📅 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

2023-06-07 04:47:57

- reply

📅 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

2023-06-07 04:47:48

- reply

📅 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
>

2023-06-07 04:47:41

- reply

📅 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/[email protected]>
> > 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>

2023-06-07 04:47:38

- reply

📅 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

2023-06-07 04:46:53

- reply

📅 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.

2023-06-07 04:45:23

- reply

📅 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

2023-06-07 04:45:17

- reply

📅 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

2023-06-07 04:44:26

- reply

📅 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

2023-06-07 04:43:48

- reply

📅 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
>

2023-06-07 04:22:33

- reply

📅 Original date posted:2011-09-06
🗒️ Summary of this message: A developer is working on a node crawler to map out the Bitcoin network and provide useful statistics, using a mutilated bitcoinj to connect.
📝 Original message:I've got minna patches for nio based on bitcoinj. I've enumerated the
network a few times and am working on a DNS seed service as well as some
weather reports.
Happy to start a branch when the committers are ready.
-rick
On Tue, Sep 6, 2011 at 12:42 AM, Steve <shadders.del at gmail.com> wrote:
> Hi All,
>
> I started messing around today with building a node crawler to try and
> map out the bitcoin network and hopefully provide some useful
> statistics. It's very basic so far using a mutilated bitcoinj to
> connect (due me being java developer and not having a clue with c/c++).
> If it's worthwhile I'll hack bitcoinj some more to run on top Netty to
> take advantage of it's NIO architecture (netty's been shown to handle
> 1/2 million concurrent connections so would be ideal for the purpose).
>
> Hoping to a get a bit of input into what would be useful as well as
> strategy for getting max possible connections without distorted data. I
> seem to recall Gavin talking about the need for some kind of network
> health monitoring so I assume there's a need for something like this...
>
> Firstly at the moment basically I'm just storing version message and the
> results of getaddr for each node that I can connect to. Is there any
> other useful info that can be extracted from a node that's worth
> collecting?
>
> Second and main issue is how to connect. From my first very basic
> probing it seems the very vast majority of nodes don't accept incoming
> connections no doubt due to lack of upnp. So it seems the active crawl
> approach is not really ideal for the purpose. Even if it was used the
> resultant data would be hopelessly distorted.
>
> A honeypot approach would probably be better if there was some way to
> make a node 'attractive' to other nodes to connect to. That way it
> could capture non-listening nodes as well. If there is some way to
> influence other nodes to connect to the crawler node that solves the
> problem. If there isn't which I suspect is the case then perhaps
> another approach is to build an easy to deploy crawler node that many
> volunteers could run and that could then upload collected data to a
> central repository.
>
> While I'm asking questions I'll add one more regarding the getaddr
> message. It seems most nodes return about 1000 addresses in response to
> this message. Obviously most of these nodes haven't actually talked to
> all 1000 on the list so where does this list come from? Is it mixture
> of addresses obtained from other nodes somehow sorted by timestamp?
> Does it include some nodes discovered by IRC/DNS? Or are those only used
> to find the first nodes to connect to?
>
> Thanks for any input... Hopefully I can build something that's useful
> for the network...
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development 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/20110906/8c63140e/attachment.html>

2023-06-07 04:18:10

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: A discussion about the possibility of replacing hard limits on block size with something that can adapt dynamically, but it is deemed too early to make such a change.
📝 Original message:On Wed, Aug 24, 2011 at 10:19 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> On Wed, Aug 24, 2011 at 1:07 PM, Rick Wesson
> <rick at support-intelligence.com> wrote:
> > 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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/7ffd3502/attachment.html>

2023-06-07 04:18:03

- reply

📅 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>

2023-06-07 04:17:47

- reply

📅 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>

2023-06-07 04:17:41

- reply

📅 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>

2023-06-07 04:15:29

- reply

📅 Original date posted:2011-08-11
🗒️ Summary of this message: Gavin Andresen is prioritizing network health and metrics, and requests a volunteer to be the Bitcoin Network Health Inspector. Rick has already started working on this project.
📝 Original message:On Wed, Aug 10, 2011 at 9:29 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> I've been wading through the pull requests and bug lists to figure out
> a roadmap for the next few months.
>
> Here are the things on my priority list:
>
> 1. Where are we at with network health? What metrics should we be
> using? Is there work to be done?
> And meta-issue: can somebody volunteer to be the Bitcoin Network
> Health Inspector to keep track of this?
>
>
I'm already on it, leveraging bitcoinj to do the work. I've added async
capabilities to bitcoinj so that I can peer with everything that will let me
with the goal of publishing quality peer lists via the DNS. Once I can build
some metrics off the network its a matter of creating the visualizations.
I just started on this project last week. Happy to work with others on what
a healty network looks like as well as best ways to communicate status.
also need advise on how to not be an impolite peer.
-rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110811/2d1e0271/attachment.html>

2023-06-07 04:10:57

- reply

📅 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>

2023-06-07 04:10:50

- reply

📅 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>

2023-06-07 04:09:11

- reply

📅 Original date posted:2011-07-30
🗒️ Summary of this message: The author suggests seeding the test suite with simple tests for each part of the codebase to encourage contributors to add more tests.
📝 Original message:+1
Putting a bounty on the test framework might put some loose change to work.
http://code.google.com/p/googletest/ would be my choice
the list of c++ frameworks is at
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B
-rick
On Sat, Jul 30, 2011 at 4:49 AM, Mike Hearn <mike at plan99.net> wrote:
> I've worked on open source projects for over 10 years now. This
> dynamic always exists but I've never seen it seriously kill a project.
>
> Thoughts:
>
> - People who start out with features often stick around and become
> core contributors.
> - Unit tests are critical.
>
> Now there's a basic skeleton for unit tests, the bug debt can start to
> be paid down by insisting that anyone who touches a piece of code
> introduces tests, whether it be for new features or refactorings.
> Insist patches won't be accepted without some new tests. In an
> untested codebase, adding or improving tests often reveals other bugs
> that then get fixed at the same time.
>
> People usually don't want to write tests if there's nothing there
> already. So I'd suggest seeding the test suite with a small number of
> simple tests for each part (wallet, net, db, etc). Once there are a
> few tests already it's easier to get people to add more. It's tempting
> to say, well, the wallet or re-org handling or whatever is the most
> critical so we'll write lots of tests for that first and do the rest
> later, but that's not as conducive to getting people to help.
>
> Most complex projects need some unit testing infrastructure to assist.
> For instance, the ability to use mock network connections or minimal
> difficulty chains. So if you build up that infrastructure and plant
> those seeds, it'll be easier for other people to flesh it out.
>
> Final thought - big test suites take a long time to grow, especially
> in codebases developed without them. A good start is a manually
> written test plan, that just walks you through the apps features.
> Insisting that a patch be signed off as passing the test plan is a
> good way to avoid gigantic breakages like the wallet encryption bug
> from cold start, at the cost of slowing down development (nobody likes
> doing manual test work over and over).
>
> I don't always follow my own advice on this and usually end up
> regretting it ....
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 04:08:35

- reply

📅 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>

2023-06-07 04:07:53

- reply

📅 Original date posted:2011-07-26
🗒️ Summary of this message: DNS-based resolving for Bitcoin addresses is risky due to potential MITM attacks. DNSSEC is not a solution. HTTPS is a better option with no significant drawbacks.
📝 Original message:[snip]
> I totally agree, however I don't think DNS-based resolving is a good
> idea here. HTTPS does have several advantages over a DNSSEC-based
> solution without any significant drawbacks that I can see.
To restate your (con dnssec) points:
o DNS resolution of bitcoin addresses is bad because of potential
MITM attacks
o DNSSEC is not a security measure for mitigating DNS resolution of
bitcoin addresses
because the application would require its own dnssec enabled stub resolver
Please restate
o HTTPS is your preferred method for resolution because?
If you can enumerate your advantages so I can develop a proper
response to the points you have raised.
thanks,
-rick

2023-06-07 04:07:43

- reply

📅 Original date posted:2011-07-30
🗒️ Summary of this message: The author offers patches for DNS lookup, but suggests a standardized HTTPS protocol for Bitcoin URI containing a domain name for better usability.
📝 Original message:I'm offering patches for DNS lookup, which seems good enough to locate
the irc server but not good enough for the folks that use copy/paste.
from a usability standpoint, the clipboard isn't a UI element in flow
design. Its also subject to MITM attacks for the most popular OSes.
Finally, think beyond you and your friends to how you can buy coffee
at starbucks easier and faster than with a starbucks card. Thats how
you make successful apps and protocols.
Has anyone offered to write the mythical
https-address-resolver-easy-button for bitcoind?
-rick
On Sat, Jul 30, 2011 at 4:34 AM, Mike Hearn <mike at plan99.net> wrote:
> This was already discussed on the forums, but clear use cases would be helpful.
>
> I originally thought this feature seemed like a no-brainer, but
> randomly emailing money to people out of the blue is not a very common
> operation. You almost always have contact with them first, if only to
> say "hey, I'm going to send you some money", but more commonly to
> figure out how much you're going to pay and what for.
>
> Once you have communication, providing an address in-band isn't very
> hard, and it has the advantage of always working. Doing anything with
> DNS or magic HTTPS endpoints means that 90% of the time, your feature
> *will not work* (eg it won't work for any gmail/yahoo/hotmail account)
> and users will rapidly learn not to bother trying as they have no way
> of knowing if any given address will work or not.
>
> It's not smart UI design to provide users with a feature that will
> normally never work, and for which they can't even guess at whether it
> will.
>
> What would be better to see is a standardized (probably HTTPS based)
> protocol in which a Bitcoin URI could contain a domain name, and then
> your client would challenge the domain to sign a nonce with the key
> corresponding to the address (or raw pubkey). This means in your
> client the payment can be rendered and recorded as a payment to
> "foobar.com", which is much more helpful. That protocol could then be
> extended to support "user at foobar.com" type challenges so when a
> bitcoin: link is provided, the server is challenged to prove ownership
> by that user of that public key. It means the details are hidden and
> when the feature is present, the UI gets silently better, but there's
> never any demand on any users to do anything different. The "copy
> Bitcoin address" button in the UI can provide the clipboard with both
> text/plain and text/html content so the right one is picked depending
> on context.
>

2023-06-07 04:07:27

- reply

📅 Original date posted:2011-07-26
🗒️ Summary of this message: Proposal to alleviate the need for unique Bitcoin addresses per transaction by using a SRV lookup and HTTPS request for Bitcoin address resolution.
📝 Original message:>
> 1. Right now you practically need a unique Bitcoin address per transaction.
I'd like to find ways to alievate this requirement.
> 2. DNSSEC is on the edge of becoming illegal in the US.
really, pointers please. DHS was a huge funder for DNSSEC asn .mil was
the first domain to deploy it. I think you may be miss-informed.
> 3. Emails aren't merely domains.
correct, I was speaking about an "address" that used the same/simular
formatting but did not use the SMTP protocol.
-rick
> I would propose something like resolving foo at bar.net to a SRV lookup for
> _bitcoinaddressresolution._tcp.foo.bar.net, expecting a cert for bar.net,
> making a HTTPS request for /bitcoinaddressresolution?foo at bar.net, and also
> sending an email to foo at bar.net (the usual way) signed with the keys used for
> the transaction. ;)
>

2023-06-07 04:07:21

- reply

📅 Original date posted:2011-07-26
🗒️ Summary of this message: A proposal was made to support DNS lookups to publish a TXT record in the DNS with a wallet address to facilitate sending of coin. However, using URIs is simpler and more secure.
📝 Original message:Matt,
I started from the premise that I can't remember a bitcoin address but
I can/do remember email addresses which, as an identity are easy
labels for humans to remember. The IPv4 address is the metaphor I
consider. As someone who actually worked on parts of DNSSEC I do
believe in it -- and that it offers reasonable security for
transactions.
Remember MITM attacks on DNS for a transaction are for the sender
against the merchant, and it is only the wallet ID that would be
available. These identifiers are something people use "like" an
identity in that they are frequently shared in public spaces.
Also, a DNS mapping does not prevent or deny anyone from leveraging
HTTP(S) for simular mapping. My point is that DNS is designed for name
to thing mapping and its done a decent job. What I like about the DNS
is that it is frequently leveraged as a proxy for identity and http
URIs are not. Where https://wesson.us/ricks-bitcoin-address doesn't
feel like and identity (to me) and rick.wesson.us does.
My point is about usability and user experience. Bitcoin if used in
the DNS might make DNSSEC more popular which IMHO is a good thing.
-rick
On Mon, Jul 25, 2011 at 6:35 PM, Matt Corallo <bitcoin-list at bluematt.me> wrote:
> On Mon, 2011-07-25 at 17:29 -0700, Rick Wesson wrote:
>> I've just joined the list with the goals of producing a patch to
>> sendtoaddress in rpc.cpp to support DNS lookups so that one could
>> publish a TXT record in the DNS with their wallet address to
>> facilitate sending of coin.
>
> But...why?
> Using URIs is much simpler and can be more useful in terms of being able
> to give different addresses and/or values per user.
> Also, despite DNSSec being "out there" DNS is still very insecure to
> transmit something that will result in money transfer...some idiot tries
> it on public WiFi and a MITM steals your coins...DNS is really just not
> well suited for this kind of thing.
> If you want nice name->address mapping, a simple HTTPS server with
> addresses and client support (there are some patches around for this)
> works much better in the end.
>
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

2023-06-07 04:07:14

- reply

📅 Original date posted:2011-07-25
🗒️ Summary of this message: A proposal to support DNS lookups for publishing a TXT record in the DNS with a wallet address to facilitate sending of coin.
📝 Original message:I've just joined the list with the goals of producing a patch to
sendtoaddress in rpc.cpp to support DNS lookups so that one could publish a
TXT record in the DNS with their wallet address to facilitate sending of
coin.
I'm proposing something like the code below, which works but needs
additional error handling.
also working on a internet-draft to describe how to put bitcoin addresses in
the DNS which I hope to post the first draft of this week.
I'd appreciate comments on issues around annomity, community push back and
any other issues you might have with leveraging the DNS for bitcoin
transactions.
thanks,
-rick
Value sendtoaddress(const Array& params, bool fHelp)
{
if (fHelp || params.size() < 2 || params.size() > 4)
throw runtime_error(
"sendtoaddress <bitcoinaddress> <amount> [comment]
[comment-to]\n"
"<amount> is a real and is rounded to the nearest 0.00000001");
/**
; <<>> DiG 9.7.3 <<>> _btc.rick.wesson.us txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43754
;; 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. 300 IN TXT "BTC=1;
1GCVXLfF1TcpnnDLJRHk845NZhuJWQTnUD"
;; Query time: 143 msec
**/
string strAddress = params[0].get_str();
string dname="_btc.";
if(strAddress.find("@")){
unsigned char answer[255];
int len=0;
dname.append(strAddress);
dname.replace(dname.find("@"), 1, ".");
if((len = res_query(dname.c_str(), C_IN, T_TXT, answer, PACKETSZ)) <
0) {
string dnsAnswer=(char*)answer;
int i=dnsAnswer.find("BTC=1;");
if( i < 0) throw runtime_error( dname + " is not associated with a
bitcoin address");
i += 6;
i = dnsAnswer.find("1", 6) ; // address start with a one (1)
dnsAnswer.erase(0,i);
strAddress=dnsAnswer;
}
}
// Amount
int64 nAmount = AmountFromValue(params[1]);
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110725/56cd48d3/attachment.html>