I am excited to announce Coinvoice, a new Bitcoin payment processing service that allows businesses to invoice for goods and services worldwide in U.S. Dollars (USD) and get paid in Bitcoins (BTC). Coinvoice makes it easy for any merchant to receive BTC without them or their customers having to worry about the infrastructure necessary to conduct and process these transactions. So long as the merchant’s customers can pay in USD via wire transfer, certified check or money order, Coinvoice will pay out to the merchant in BTC.

The idea for Coinvoice arose out of a handful of conversations I had regarding Bitcoins and receiving payment for invoices using cryptocurrencies more generally. I had remarked to one of my associates that “it would be great to take payment for invoices in BTC”, but I acknowledged that it was a serious pain point to dictate to all of your customers “now you need to go get BTC to pay me”. Then I went on to suggest I would be willing to give a discount on the invoice amount if they paid in BTC, and the seed for Coinvoice was sowed.

Beyond making a business out of the scenario I described above, Coinvoice is meant to fulfill a vital need in the Bitcoin economy: putting BTC in the hands of business owners with less friction. Enabling businesses to more easily access BTC is overall a positive thing for the Bitcoin economy, and it will have positive secondary effects, e.g. more customers for sites that accept direct BTC payments. More generically, Coinvoice is meant to enable payment settlement from USD to BTC, whereas most existing payment processing services are built to facilitate settlement from BTC to USD or solely in BTC.

Our target audience with Coinvoice is pretty much any business that wants to have customers pay in USD and ultimately receive BTC as payment for goods and services. A few examples of the kinds of businesses I’m talking about are:

• IT contractor that invoices for their work at the end of each month
• Chinese manufacturer that sells goods in the US
• Vanuatu IBC that licenses intellectual property in the US

       
Coinvoice is meant to be used in a “traditional” business setting where invoices are issued and paid a number of days afterwards.

We are looking forward to enabling businesses to settle payments in BTC and helping grow the larger Bitcoin ecosystem. Coinvoice provides you with a safe, private, reliable and secure way for your business to receive BTC.

i saw a few of these scroll by on blockexplorer.com in the past few days: blocks with zero tx besides the BTC 25 award to the miner. have also seen some with just a few tx in them.

recent examples are 234221 and 234217.

am i missing something here or is someone mining empty blocks? seems like a rude thing to do. i am guessing there is some edge to mining empty blocks.

NOTE: i have syndicated this content from https://blog.conformal.com/ so readers don't need to visit the site.

btcd is an alternative full-node implementation of the bitcoin protocol written in Go and is currently under active development. btcd has been under development for 10 weeks and the initial code is nearly ready for public release. We feel that by providing an alternative to bitcoind we can substantially improve the diversity and resilience of the bitcoin ecosystem and infrastructure.

A number of us at Conformal Systems had been keeping an eye on bitcoin as passive observers for the past couple years since bitcoin combines technologies that are already of interest to us: practical use of cryptography, distributed systems, and electronic payments. In January 2013 I had one of our developers, David Hill, attempt to port bitcoind and its GUI to Bitrig, an OS that several of our developers forked from OpenBSD. David encountered several problems with porting to Bitrig and in the process found issues with unit tests, non-portable functions and seeding of a PRNG. While pushing to get the port complete, it was clear that it would take a lot more effort than usual to complete this port. After seeing these issues with the porting, I felt that the bitcoin ecosystem could use an alternative to bitcoind.

Until starting on btcd, most of our developers had written almost exclusively in C. Our CTO, Marco Peereboom, and developers had been pushing for a new project written entirely in Go. Writing a bitcoind replacement seemed like an interesting project that would take less than 6 months to complete. Once discussion on btcd began in earnest, it became clear that using Go offered a number of advantages over C or C++, especially for financial software:

• integrated test infrastructure
• no active memory management
• standard formatting
• platform independent code
• simpler parallelism
• virtually crash-proof
• built-in profiling and documentation facilities

The most important Go feature in the context of btcd is that of the test infrastructure: by having robust test infrastructure from the outset, all code can and shall have test coverage. Having full test coverage will ensure that most bugs are caught early in the development cycle, before they cause widespread problems. Since btcd is financial software and errors could lead to someone losing money, we take test coverage particularly seriously.

btcd is a work-in-progress and we will be making the initial source code release in the next couple weeks. At the moment, we have approximately 40% test coverage on our code but we will be expanding our test coverage once more of the core functionality is complete. We have setup btcd at our colocation facility and are using it to generate output similar to blockexplorer.com, have a look at blocksafari.com to see btcd-generated output.

Currently, the following components of btcd are tested as working:

• Discovery
• Protocol
• Crypto, hashing, base58 etc
• Populating the block database
• Serve blocks from the database
• Peer-to-peer manager
• IPv6 and IPv4 connectivity
• Execute all transaction scripts currently in use
• JSON RPC that deals with blocks and transactions
• Verification of transaction signatures

Most of the code is in pretty good shape however some pieces are incomplete. Within 2 weeks we should have enough core functionality written and at that point we are going to release parts of the code to the general community. After this initial release, we plan on adding new functionality to handle wallets, Tor connectivity, etc.

If you are interested in talking to our developers about btcd, come chat on our public IRC server in channel #btcd.

in the past 5 days, the price of BTC has fluctuated wildly, mostly as a result of panic induced by erratic service at MTGOX. there have been a variety of explanations, none of which are particularly reasonable. i think MTGOX and the BTC market in general could benefit from more transparency.

(A) "MTGOX is victim of its own success" - the claim being that so many account registrations have swamped their system. this is the public position from MTGOX. unless the website is coded like total crap, i do not believe that 75,000 account registrations occurring in approximately 10 days will substantially affect the load on a database. sure, it means more action on the web interface but a simple option is to temporarily put a freeze on creating new accounts or rate limit it.

(B) "the volume of trades has seized their trading engine" - this is pretty unbelievable when you consider the volume shown for trading over the past several days. it could be the case that the trading engine is really hacked together, e.g. using perl scripts or some web 2.0 turd infrastructure, in which case i could understand why this is not what MTGOX wants to publicly discuss. in the case that many "small" trades are killing their engine, it would make sense to limit trades to a minimum size.

(C) "the site is under a persistent and sophisticated DDoS" - i consider this the most likely problem despite MTGOX having been dismissive of it recently. the extent and nature of the current issues does not fit either explanation (A) or (B).

i have many years of experience with people bullshitting me or otherwise trying to scam me, and the official explanations (A and B from above) do not pass my smell test. i think it's about time MTGOX finally started telling people what the hell is actually going on.

something i find rather disconcerting about bitcoin is a lack of justification/explanation for some of the design decisions, in particular the choice of doing 256-bit ecdsa keypairs over secp256k1 vs secp256r1 (a.k.a. P-256) for wallets.

the best i could find on the forum is this thread from 2011 - https://bitcointalk.org/?topic=2699.0

NIST recommends use of secp256r1, and more generally prefers random curve parameters to the Koblitz ones. i can only speculate why this choice was made, here are a couple possible reasons:

* NIST sets standards for NSA / US govt crypto and is genuinely concerned about everyone's security. they have found that random curves are more secure than Koblitz ones.
* NIST has made an intentionally poor suggestion to use secp256r1, so it acts as a honeypot. they have found that Koblitz curves are actually more secure than the random ones.

with those reasons in mind i could see bitcoin having analogous justifications:

* Satoshi had information which led him/them to believe that secp256r1 was indeed a honeypot and that secp256k1 was the better choice for real security
* Satoshi knew that secp256k1 was weak and intentionally included it in bitcoin to make bitcoin into a honeypot

considering that the design decisions for both BTC and NIST ciphers are both entirely opaque, it is difficult to make a good guess as to their motivation. i have similar reservations about using base58 everywhere, but that is less a concern from a security perspective.

can anyone provide a justification for using secp256k1 over secp256r1 besides "that's just the way it is" or "so it was written in the great book"?

hello bitcoin forum ppl

i have registered at this forum because i have a pretty narrow interest set: participating in the development and technical discussion subforum. however, i cannot have any substantive interactions until my account has become "unrestricted", just like every n00b. this is, hands down, the most irritating vetting process i have ever experienced at any forum to date.

i can certainly understand why, in general, such rules are in place since i admin a forum or two myself (fluxbb) and am familiar with how rampant the spammers and trolls can become. most forums where there are posting or new thread restrictions there is a more moderate restriction on what activities can be undertaken by an unverified user. as it currently stands, i am restricted to this subforum which can be summarized as "the short bus" where people talk about the sandwich their mom made them today or that BTC/USD is going up.

on top of this being a giant waste of my time, the "Total time logged in" count is entirely fucking broken for me. i have remained logged in, read a bunch of technical discussion posts, etc, and i am, somehow, only at 1 hr 35 minutes of logged in time. in fact, while i was drafting this post the timer has gone from 1 hr 34 min to 1 hr 35 min. a whole minute... when i have spent easily 10-15 minutes typing all this out.

NOTE: i am using an non-standard browser, xombrero, and i have white-listed this forum for js and cookies.

if you're at disney world in FL, you'll get to see some great stuff with people who aren't from the US. this may include seeing an irish man slap his whining and fighting kids. it was quite a spectacle.