The Carolinas first-ever Bitcoin Expo will be kicked off in Raleigh on August 15 and 16, 2014. Cryptolina will be held at the Raleigh Convention Center. It will serve as a gateway to hundreds of new interested businesses, investors, and enthusiasts. Cryptolina follows successful Bitcoin conferences held in cities throughout the world, including Miami, Hong Kong, Washington, San Francisco, New York City, and Amsterdam.
More than 500 new faces of the emerging Bitcoin community are expected to attend, network and discuss this emerging industry behind the digital currency. Cryptolina’s announcement comes on the heels of several positive Bitcoin evaluations including acknowledgement by the Federal Reserve that “Bitcoin does not present a threat to economic activity by disrupting traditional channels of commerce; rather, it could serve as a boon."
Cryptolina is being held in Downtown Raleigh in order to capitalize on the flourishing startup scene and exponential growth. Frequently cited as a "New Silicon Valley" of the East Coast, the Research Triangle region is a natural fit due to the high-tech jobs and leading companies.
Current issues and events pertaining to Bitcoin technologies, startups, venture capital investment and angel investment will be discussed during multiple panels. In addition to a Bitcoin based business exhibition, there are plans to host nearly two dozen speakers.
For additional information regarding the upcoming Cryptolina Bitcoin Expo, contact us at info@cryptolina.com
* Add new icons for Developer Guide and Developer Examples so we don't
keep reusing the book icon.
* Update payment protocol links to point to developer examples when
appropriate.
Two minor changes suggested by iwilcox on IRC (thanks!):
* s/brute-force find/brute-force/ in HD wallet section
* Correct mistaken assertion that the keypool isn't refreshed until all
keys are used. If the wallet is unencrypted or unlocked, the keypool
is refreshed after each time a key is used.
* Remove contentious sentence about mining non-standard txes possibly
creating orphaned blocks and loss of block reward. Suggested by
@luke-jr (thanks!)
* Remove unnecessary value judgement ("unfortunately") against
non-standard redeemScripts. Mention that they can be used deliberately
by someone who wants to easily receive payment to a non-standard
output script. Suggested by @luke-jr (thanks!)
Based on a discussion tonight on IRC with comments from @gmaxwell,
bitcoin428, and kadoban.
* Add a new introduction to the Standard Transaction section which
explains the purpose behind standard transactions so readers
understand that these aren't limitations for limitation's sake. More
specifically, note that bug-prevention isn't the only reason for
standard transactions---thanks to @gmaxwell for explaining the forward
compatablity reason to me.
* Make it clear that isStandard() only applies to loose transactions and
that it doesn't apply to txes in blocks. Thanks to bitcoin428 for
pointing out this source of confusion.
* Make it cleare that a non-standard redeemScript is a script that would
not pass isStandard(). Thanks to kadoban for pointing out the absense
of that information.
* Add new Developer Examples page
* Add a transaction tutorial describing in detail how to make various
different transactions.
* Add a new "multicode" CSS class to allow combination of consecutive
code blocks into a single code block. This lets us use pygments
highlighting for multiple different types of code within the same
aparent block of code.
* Get autocrossref to ignore code blocks so we don't need to endcrossref
every time we encounter a code block. This makes the source much more
readable and maintainable.
Two unrelated minor additions which were requested at nearly the same
time.
* @mikehearn requested we add a link to @gavinandresen's PaymentRequest
generator. Added to _includes/guide_payment_processing.md with link
definition in _includes/references.md
* @Burrito-Bazooka requested we mention that the block reward halves
every 210,000 blocks. Added to _includes/ref_block_chain.md
