https://en.bitcoin.it/w/api.php?action=feedcontributions&user=XertroV&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-29T10:55:52ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=Free_transaction_relay_policy&diff=56309Free transaction relay policy2015-05-11T00:45:16Z<p>XertroV: /* How to use or participate */ add link to eligius search on getaddr.bitnodes.io</p>
<hr />
<div>The original client currently refuses to relay transactions it considers "unacceptable". However, there may be miners that are willing to put these in a block. This group is for people who want to send such transactions, and those who want to put them in blocks.<br />
<br />
Simply have your node maintain a connection to Lightfoot Hosting's node, which relays indiscriminately. This means that you can broadcast your transaction to it, and it will relay it to any miner who also has a connection to it. If your transaction meets the policies of at least one miner connected, it should eventually get into a block.<br />
<br />
== How to use or participate ==<br />
<br />
=== bitcoind / Bitcoin-Qt ===<br />
Add the command-line parameter: -addnode=68.168.105.168<br />
<br />
If this IP address stops working you can find potential eligius nodes here: https://getaddr.bitnodes.io/nodes/leaderboard/?q=eligius<br />
<br />
== Participating miners ==<br />
<br />
{| class="wikitable sortable"<br />
! Miner !! Minimum Fee (BTC) !! Cost per KB !! Non-standard Tx !! Other Policy Notes<br />
|-<br />
| [[Eligius]] || 0.2 TBC (0.00008192 BTC) || 0.2 TBC || {{Table Value Yes}} || 2 TBC/KB at larger sizes<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Transaction fees]]<br />
<br />
[[Category:Mining]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=Free_transaction_relay_policy&diff=56308Free transaction relay policy2015-05-11T00:44:04Z<p>XertroV: /* bitcoind / Bitcoin-Qt */ update IP to add</p>
<hr />
<div>The original client currently refuses to relay transactions it considers "unacceptable". However, there may be miners that are willing to put these in a block. This group is for people who want to send such transactions, and those who want to put them in blocks.<br />
<br />
Simply have your node maintain a connection to Lightfoot Hosting's node, which relays indiscriminately. This means that you can broadcast your transaction to it, and it will relay it to any miner who also has a connection to it. If your transaction meets the policies of at least one miner connected, it should eventually get into a block.<br />
<br />
== How to use or participate ==<br />
<br />
=== bitcoind / Bitcoin-Qt ===<br />
Add the command-line parameter: -addnode=68.168.105.168<br />
<br />
== Participating miners ==<br />
<br />
{| class="wikitable sortable"<br />
! Miner !! Minimum Fee (BTC) !! Cost per KB !! Non-standard Tx !! Other Policy Notes<br />
|-<br />
| [[Eligius]] || 0.2 TBC (0.00008192 BTC) || 0.2 TBC || {{Table Value Yes}} || 2 TBC/KB at larger sizes<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Transaction fees]]<br />
<br />
[[Category:Mining]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=Meetups&diff=46970Meetups2014-05-04T04:50:30Z<p>XertroV: Update BitcoinSYD</p>
<hr />
<div>Don't add everyone who's going in the "Who?" column, just prominent Bitcoin members and organizers. Also see [http://bitcoin.meetup.com bitcoin.meetup.com]. Also see [[Conferences]].<br />
<br />
Keep an eye on the [http://bitcointalk.org/index.php?board=86.0 Meetups] forum board on BitcoinTalk for announcements.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Group<br />
! When?<br />
! Where?<br />
! Who?<br />
! Other Notes<br />
|-<br />
| [http://bitcoinembassy.ca Bitcoin Embassy]<br />
| Monthly meetups, weekly workshops<br />
| Montreal, QC, Canada<br />
| Local and international participants - guest speakers welcome. Come and visit our hackerspace, startup incubator and soon, Bitcoin store.<br />
| Presentations and workshops, discussion & trade. [http://eepurl.com/GRzAf Register to our mailing list] to receive event invitations. We also post on [https://bitcointalk.org/index.php?board=86.0 BitcoinTalk Meetups], [http://bitcoinembassy.eventbrite.ca/ EventBrite], [https://www.facebook.com/bitcoinembassy Facebook Bitcoin Embassy page], [https://plus.google.com/u/0/100266464273886488866 Google +], etc.<br />
|-<br />
|-<br />
| [http://www.meetup.com/BitcoinCT/ BitcoinCT Meetup]<br />
| Monthly Meetups<br />
| Stamford, CT<br />
| The Connecticut Bitcoin Meetup brings together Bitcoin users in Connecticut. This meetup is suitable for everyone from Bitcoin newbies to experienced Bitcoiners. You can attend meetups simply to learn more about Bitcoin or to make business connections for entrepreneurs, miners and developers. | We welcome everyone to our meetups even if you're not currently a Bitcoin user, but simply want to find out more about this amazing e-currency. <br />
|-<br />
|-<br />
| [https://bitcash.cz/forum/ Bitcash.cz]<br />
| Ocasionally<br />
| Prague, Brno, Ostrava<br />
| Meetup for Czech and Slovak bitcoin pioneers. <br />
| Discuss and trade with Bitcoin. Events posted also on our [https://www.facebook.com/Bitcash.cz Facebook] profile.<br />
|-<br />
|-<br />
| [http://www.meetup.com/Sydney-Bitcoin-Users-Group/ BitcoinSYD]<br />
| Every Wednesday @ 1800<br />
| [https://goo.gl/maps/okdSm The SG], Downstairs, 32 York St. Look for the guy in the Red Cap.<br />
| Local, National and International peeps looking to Talk and Trade Bitcoin<br />
| We also post our meetups on Reddit and [https://www.facebook.com/pages/Bitcoin-Sydney-Australia/457681220943285 Facebook]<br />
|-<br />
|-<br />
| [https://bitcointalk.org/index.php?topic=27191.0;all Bitcoin Stammtisch]<br />
| each first Thursday of the month<br />
| [http://www.room77.de/ Room 77], Gräfestr. 77, Berlin-Kreuzberg<br />
| Anyone interested in Bitcoin: technically, economically, socially or philosophically.<br />
| If questions contact andreas(at)schildbach.de (founder).<br />
|-<br />
|-<br />
| [http://www.meetup.com/bitcoins/ Bitcoin NYC]<br />
| monthly<br />
| [http://www.xcubicle.com/ xCubicle Hackerspace - New York, NY]<br />
| Any and all Bitcoin aficionados. <br />
|<br />
|-<br />
|-<br />
| [https://en.bitcoin.it/wiki/Bitcoin_Wednesday Bitcoin Wednesday Amsterdam]<br />
| First Wednesday of the Month<br />
| Dutch Bitcoin Users Group of the Netherlands - The country's longest continuously running Bitcoin event.<br />
| [http://www.meetup.com/BitcoinWednesday/ Sign Up - Amsterdam, The Netherlands]<br />
| Open to anyone interested in Bitcoin. Organized by [https://www.PikaPay.com PikaPay.com] @PikaPay or hello-AT-PikaPay.com<br />
|-<br />
|-<br />
| [http://hitspace.org/ HIT Space - Hack it Together]<br />
| monthly<br />
| [http://hitspace.org/where-we-are/ HIT Space - Porto, Portugal]<br />
| Hackerspace members and anyone who want to join us<br />
| send us an email geral[at]hitspace.org<br />
|-<br />
|-<br />
| [http://bitcoin-austria.at Bitcoin Austria]<br />
| monthly - check the [http://bitcoin-austria.at wiki] or subscribe to the [http://lists.bitcoin-austria.at/listinfo/bitcoin mailinglist]<br />
| [https://metalab.at/wiki/Lage Metalab], Vienna hacker space, Rathausstraße 6, 1010 Wien<br />
| Everybody interested in Bitcoin <br />
| <br />
|-<br />
| [http://brmlab.cz brmlab, prague hackerspace]<br />
| 14th Nov 2011<br />
28th Nov 2011<br />
([http://brmlab.cz/event/bitcoin_seminar])<br />
| [http://brmlab.cz/place Brmlab, Bubenska 1]<br />
| brmlab crew, slush, genjix<br />
| <br />
|-<br />
| [http://www.facebook.com/groups/175596065827848/ Bitcoin Boston]<br />
| Every Friday at 4:30 and bi-weekly on Saturday or Sunday ([http://www.facebook.com/groups/175596065827848/ See Facebook page])<br />
| Starbucks in Kendall Square (Ames St & Broadway) and bi-weekly at Starbucks in Harvard Square<br />
| Anyone is welcome!<br />
| Our bi-weekly meetings have been somewhat sporadic but we aim to gain some regularity.<br />
|-<br />
| [http://www.meetup.com/Milwaukee-Area-Bitcoin-Meetup/ Milwaukee Area Bitcoin Meetup]<br />
| Every other Thursday at 6:00pm<br />
| 17025 West Rogers Drive, New Berlin WI<br />
| Open to anyone interested in Bitcoin<br />
| [https://www.facebook.com/groups/BTCMKE Milwaukee Area Bitcoin Meetup Facebook]<br />
|-<br />
| [http://www.meetup.com/bitcoin New York Bitcoin Users]<br />
| 6:00 PM, 3rd Sunday of every month ([http://www.meetup.com/bitcoin/events/past past meetings])<br />
| OnlyOneTV Studios - 290 Fifth Ave New York, NY<br />
| Bruce Wagner (Organizer) and others<br />
| <br />
|-<br />
|-<br />
| [http://www.meetup.com/bitcoin New York Bitcoin Users]<br />
| 6:00 PM, every Wednesday of every month ([http://www.meetup.com/bitcoin/events/past past meetings])<br />
| Just Sweet Dessert House - 83 Third Ave New York, NY<br />
| Yifu Guo (Organizer) and crew<br />
| hosted by Bitsyncom, the people behind [[Bitnavigator]], walk-ins welcome;<br />
|-<br />
|[http://www.meetup.com/MichiganBitcoinMeetup Michigan Bitcoin Meetup]<br />
|<br />
|<br />
|Kinnard Hockenhull (Organizer)<br />
|Sponsored by [[BitBox]]<br />
|-<br />
| [http://www.meetup.com/PhillyBitcoin Philadelphia Bitcoin User Group]<br />
| TBD<br />
| TBD<br />
| Brian Cohen (Organizer) and others<br />
|<br />
|-<br />
| [http://www.meetup.com/BitcoinDC Washington, DC Bitcoin Users]<br />
| 7:00 PM, 1st Monday of every month ([http://www.meetup.com/BitcoinDC/#past past meetings])<br />
| Northside Social, 3211 Wilson Blvd Arlington, VA<br />
| [[User:Dduane|Darrell Duane]] (Organizer) and others<br />
|<br />
|-<br />
| [http://www.meetup.com/Silicon-Valley-Bitcoin-Users Silicon Valley Bitcoin Users]<br />
| 7:00 PM, Tuesday, June 14, 2011 ([http://www.meetup.com/Silicon-Valley-Bitcoin-Users/events/past past meetings])<br />
| 140B S Whisman Road Mountain View, CA <br />
| Brian Mcqueen and others<br />
|<br />
|-<br />
| [http://www.meetup.com/BitcoinChicago Chicago]<br />
| No regular schedule yet ([http://www.meetup.com/BitcoinChicago/events/past past meetings])<br />
| Sunnyvale Art Gallery Cafe, 251 W El Camino Real Sunnyvale, CA<br />
| Igor<br />
|<br />
|-<br />
| [http://www.meetup.com/denver-bitcoin Denver]<br />
| First meeting June 4th, 2011 ([http://www.meetup.com/denver-bitcoin/events/past past meetings])<br />
| Gypsy House Cafe - 1279 Marion St Denver, CO<br />
| bearbones<br />
|<br />
|-<br />
| [http://www.meetup.com/bitcoinSF Bitcoin SF]<br />
| Saturday, June 4, 2011 ([http://www.meetup.com/bitcoinSF past meetings])<br />
| SFSU - 1600 Holloway Ave. San Francisco, CA<br />
| Brian Mcqueen and others<br />
|<br />
|-<br />
| [http://www.meetup.com/Los-Angeles-Digital-Currency-Innovators-Group Los Angeles Digital Currency Innovators]<br />
| Thursday July 7th, 2011, 7 PM<br />
| (mt)/Media Temple, Culver City, CA<br />
| [[User:sgornick|Stephen Gornick]] (Interim organizer) and others<br />
| Seeking meetup coordinator<br />
|-<br />
| [http://Hackerish.org Las Vegas Crypto Party]<br />
| 3rd Thursday 7pm. [http://BitcoinsInVegas.com Weekly Wednesday lunch mobs]<br />
| /Usr/Lib @ The Beat Coffee House, 520 Fremont, 2nd floor, Las Vegas, NV<br />
| Julian Tosh / Tuxavant<br />
|<br />
|-<br />
| [https://www.facebook.com/groups/195492163844669/ Free State Bitcoin Consortium]<br />
| Every Saturday, at 6:30 PM<br />
| Strange Brew Tavern, Manchester, NH<br />
| ben-abuya (organizer)<br />
| Weekly<br />
|-<br />
| [https://www.facebook.com/groups/195492163844669/ Twin Cities Users]<br />
| Friday, June 10, 2011, 6:30 PM<br />
| Joule - 1200 Washington Ave S Minneapolis, MN<br />
| Mac Manson<br />
|<br />
|-<br />
| [http://www.meetup.com/Portland-Bitcoin-Meetup-Users Portland Bitcoin Users Meetup Group]<br />
| forming<br />
| <br />
| Steven Wagner<br />
|<br />
|-<br />
| [http://www.meetup.com/Bitcoin-Orlando Bitcoin Orlando]<br />
| ([http://www.meetup.com/Bitcoin-Orlando#past past meetings])<br />
| Frank & Steins 150 S. Magnolia Ave, Orlando, FL<br />
| Antonio Gallippi<br />
|<br />
|-<br />
| [http://www.meetup.com/Bitcoin-Enthusiasts/ Bitcoin Tampa]<br />
| Monthly meetings<br />
| Matt Branton -- [https://www.coinlock.com/ Coinlock.com] founder<br />
|<br />
|-<br />
| [http://www.hive13.org/?p=310 Hive13 Hackerspace]<br />
| Bitcoin Exchange, Every Tuesday, 7:30 PM<br />
| Hive13 - 2929 Spring Grove Avenue, Cincinnati, OH<br />
| <br />
|<br />
|-<br />
| [https://www.facebook.com/bitcoinaus Bitcoin Australia]: Melbourne <br />
| [https://www.facebook.com/events/345430765511234/ Wednesday, 23 May 2012, 18:45]<br />
| Melbourne CBD(TBA)<br />
| Facebook, IRC, Bitcointalk Forum...<br />
|<br />
|-<br />
| [[Bitcoin:Tokyo meetup|Tokyo]]<br />
| Usually first monday of the month<br />
| Shibuya<br />
| Roger Ver (Organizer) and others<br />
|<br />
|-<br />
| [http://meetup.com/Bitcoin-Canada Vancouver Canada]<br />
| ([http://www.meetup.com/Bitcoin-Canada/#past past meetings])<br />
| The Brickhouse - 730 Main St.<br />
| humble (and others)<br />
|<br />
|-<br />
| [https://plus.google.com/u/0/communities/113055238568417913658 Zurich / Geneva Switzerland]<br />
| Twice a month<br />
| Kennedy's Irish Pub, Zurich; Lord Nelson Pub, Geneva<br />
| Stefan Thomas (WeUseCoins), Mike Hearn (BitcoinJ), bitdragon, Luzius (Wuala), more ... <br />
|<br />
|-<br />
| Seattle Bitcoin Meetup<br />
| [http://www.meetup.com/SeattleBitCoin/ Semi-regularly].<br />
| [http://maps.google.com/maps?q=cafe+solstice&daddr=4116+University+Way,+Seattle,+WA+98105-6214&hl=en&ll=47.657424,-122.31313&spn=0.007328,0.01929&gl=us&view=map&geocode=CRT9Bdg7zX3vFdcx1wIdWqa1-CFcJ9qrr9CcEQ&t=h&z=16 Solstice Cafe, 2pm]<br />
| [https://bitcointalk.org/index.php?action=profile;u=36217 indolering]<br />
|<br />
|-<br />
| [https://bitcointalk.org/index.php?topic=135723.0 Munich Germany]<br />
| First wednesday of the month, 6:00PM<br />
| [http://www.openstreetmap.org/?minlon=11.5800867080688&minlat=48.1336479187012&maxlon=11.5804319381714&maxlat=48.1338386535645 Nero Pizza], Rumfordstrasse 34, 80469 München<br />
| Bitcoin-users from Munich and around<br />
| [http://www.meetup.com/Bitcoin-Munchen/ @meetup.com]<br />
|-<br />
| [http://www.meetup.com/bitcoin-il/ Israel Bitcoin Meetup Group]<br />
| Occasional<br />
| TBD<br />
| Meni Rosenfeld<br />
|<br />
|-<br />
| [http://www.meetup.com/Dallas-Bitcoin-User-Meetup/ Dallas Bitcoin Meetup Group]<br />
| Biweekly on Saturdays, 6:00PM<br />
| [http://freemandallas.com/ The Free Man Cajun Cafe]<br />
| Justus Ranvier (organizer)<br />
|<br />
|-<br />
| [https://en.bitcoin.it/wiki/Cafe Café Bitcoin Sevilla]<br />
| <br />
| Seville, Spain<br />
| Randy Brito (rdymac / btcven), Eduardo (bitcoin.com.es), Jorge and Alfredo<br />
| http://cafebitcoin.com<br />
|-<br />
| [http://www.meetup.com/Lehigh-Valley-Bitcoin-Meetup/ Lehigh Valley (Allentown/Bethlehem PA) Bitcoin]<br />
| <br />
| Westgate Subway; Schoenersville Rd; Bethlehem<br />
| Jim Hoff (organizer)<br />
| http://www.meetup.com/Lehigh-Valley-Bitcoin-Meetup/<br />
|-<br />
|}<br />
<br />
==See Also==<br />
<br />
* [http://hackerspaces.org/wiki/List_of_Hacker_Spaces List of Hacker Spaces]<br />
* [http://bitimap.net Bitimap.net - Find local meetups (up-to-date)]<br />
<br />
[[Category:Local]]<br />
[[Category:Meetups]]<br />
<br />
<br />
[[de:Treffen]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=List_of_Bitcoin_non-profits_around_the_world&diff=44595List of Bitcoin non-profits around the world2014-02-24T05:40:16Z<p>XertroV: /* United States / International: Bitcoin Foundation */ Mark Karpeles no longer on the board</p>
<hr />
<div>This page will list all the known Bitcoin and crypto-currency non-profits around the world. The criterias for being on this list are:<br />
<br />
# A focus on Bitcoin or crypto-currency (merely accepting Bitcoin donations is not enough)<br />
# Being a non-profit<br />
# The organization needs to be either a registered non-profit or in the process of active registration.<br />
<br />
= List of organizations (by country of residence)=<br />
<br />
== Argentina: Fundación Bitcoin Argentina ==<br />
* [http://www.bitcoinargentina.org/ Website]<br />
<br />
== Australia: The Bitcoin Association of Australia ==<br />
* Board members:<br />
** [[Martin Bajalan]]<br />
** [[Max Kaye]] Treasurer<br />
** [[Adam Poulton]] Secretary<br />
** [[Pantelis Roussakis]] Vice-President<br />
** [[Bret Treasure]]<br />
** [[Jason Williams]] President<br />
** [[Tristan Winters]]<br />
<br />
== Austria: Bitcoin Austria ==<br />
* [http://bitcoin-austria.at/ Website]<br />
<br />
== Belgium: Belgian Bitcoin Association ==<br />
* Directors:<br />
** [[Arne Brutschy]]<br />
** [[Chris D'Costa]]<br />
** [[Jérémie Dubois-Lacoste]]<br />
** [[Filip Roose]]<br />
** [[Thomas Spaas]] <br />
** [[Jean Wallemacq]]<br />
<br />
== Canada: The Bitcoin Embassy ==<br />
* [http://bitcoinembassy.ca website]<br />
A non-profit organization seeking to promote the adoption of Bitcoin and related crypto-technologies, as well as facilitating networking throughout the Bitcoin community in Canada and worldwide.<br />
<br />
== Denmark: The Bitcoin Association of Denmark ==<br />
* [http://www.danskbitcoinforening.dk/ Website]<br />
<br />
== Germany: Bundesverband Bitcoin e.V. ==<br />
* [http://www.bundesverband-bitcoin.de/ Website]<br />
* Board members:<br />
** [[Radoslav Albrecht]]<br />
** [[Dennis Daiber]]<br />
** [[Oliver Flaskämper]]<br />
** [[JF Gallas]] Chairman<br />
** [[Timo Hanke]]<br />
** [[Jörg von Minckwitz]]<br />
** [[Jörg Platzer]] Vice Chairman<br />
<br />
== India: Bitcoin Alliance of India ==<br />
* [http://www.bitcoinalliance.in/ Website]<br />
<br />
== Ireland: Bitcoin Foundation of Ireland. ==<br />
* [http://www.bitcoinirl.ie Website]<br />
* Board members:<br />
** [[Alan Donohoe]]<br />
** [[Vincent O Donoghue]]<br />
** [[Roger Ver]]<br />
<br />
<br />
== Israel: איגוד הביטקוין הישראלי ==<br />
See [[The Israeli Bitcoin Association]].<br />
<br />
== Italy: Bitcoin Foundation Italia ==<br />
* [https://www.bitcoin-italia.org/ Website]<br />
* Board members:<br />
** [[Andrea Medri]]<br />
** [[Davide Barbieri]]<br />
** [[Franco Cimatti]]<br />
<br />
== Netherlands: Stichting Bitcoin Nederland ==<br />
* [http://stichtingbitcoin.nl/ Website]<br />
* [http://stichtingbitcoin.nl/index.php/de-stichting/het-bestuur/ Board members]:<br />
** [[Mark van Cuijk]]<br />
** [[Jouke Hofman]]<br />
** [[Richard Kohl]]<br />
** [[Carl Kuntze]]<br />
** [[Sicco Steenhuisen]] Chairman<br />
<br />
== Sweden: The Bitcoin Association of Sweden ==<br />
* [http://www.bitcoinforeningen.se/ Website]<br />
<br />
== Switzerland: Bitcoin Association Switzerland ==<br />
* [http://www.bitcoinassociation.ch/ Website]<br />
* Board members:<br />
** [[Johann Gevers]] - Treasurer<br />
** [[Stefan Greiner]] - Secretary<br />
** [[Luzius Meisser]] - President<br />
<br />
== United Kingdom: UK Bitcoin Foundation ==<br />
* [[Adam Cleary]]<br />
* [[Paul Gordon]]<br />
* [[Eitan Jankelewitz]]<br />
* [[Tom Robinson]]<br />
* [[James Smith]]<br />
* [[Lee Welham]]<br />
<br />
== United States / International: Bitcoin Foundation ==<br />
* [http://bitcoinfoundation.org/ website]<br />
* [https://bitcoinfoundation.org/about/board Board members (alphabetically)]:<br />
** [[Gavin Andresen]] - Chief Scientist<br />
** [[Micky Malka]] - Board Member<br />
** [[Jon Matonis]] - Executive Director and Board Member<br />
** [[Patrick Murck]] - General Counsel<br />
** [[Elizabeth T. Ploshay]] - Board Member<br />
** [[Peter Vessenes]] - Chairman of the Board<br />
<br />
= Other =<br />
== Bitcoin100 ==<br />
[http://bitcoin100.org/ Bitcoin100] is a charity organization that exists specifically to convince new charities to start accepting bitcoin donations.<br />
<br />
== The Mastercoin Foundation ==<br />
See [http://wiki.mastercoin.org/index.php/The_Mastercoin_Foundation the Mastercoin wiki].<br />
<br />
== PikaPay Foundation ==<br />
<br />
The [https://PikaPay.com PikaPay Foundation] is a nonprofit dedicated to innovation in today’s financial systems and is focussed on developing the Bitcoin ecosystem.<br />
<br />
PikaPay's Mission: To explore trends in science, technology, community and culture; To overcome limitations of traditional financial services; To improve lives, empower groups and individuals; and To make greater social contributions to the world.<br />
<br />
= See Also =<br />
# [https://bitcointalk.org/index.php?topic=288677.0 bitcointalk thread]<br />
# [https://docs.google.com/document/d/1TnTCcT7fiNr5nt-oApr_7DwXAypFoJpZ6lk_w_ykwcc/edit google doc].<br />
# [[:Category:nonprofit]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=List_of_Bitcoin_non-profits_around_the_world&diff=44564List of Bitcoin non-profits around the world2014-02-22T01:19:14Z<p>XertroV: /* United States / International: Bitcoin Foundation */ - Charlie Shrem is not on the board of the Foundation any longer.</p>
<hr />
<div>This page will list all the known Bitcoin and crypto-currency non-profits around the world. The criterias for being on this list are:<br />
<br />
# A focus on Bitcoin or crypto-currency (merely accepting Bitcoin donations is not enough)<br />
# Being a non-profit<br />
# The organization needs to be either a registered non-profit or in the process of active registration.<br />
<br />
= List of organizations (by country of residence)=<br />
<br />
== Argentina: Fundación Bitcoin Argentina ==<br />
* [http://www.bitcoinargentina.org/ Website]<br />
<br />
== Australia: The Bitcoin Association of Australia ==<br />
* Board members:<br />
** [[Martin Bajalan]]<br />
** [[Max Kaye]] Treasurer<br />
** [[Adam Poulton]] Secretary<br />
** [[Pantelis Roussakis]] Vice-President<br />
** [[Bret Treasure]]<br />
** [[Jason Williams]] President<br />
** [[Tristan Winters]]<br />
<br />
== Austria: Bitcoin Austria ==<br />
* [http://bitcoin-austria.at/ Website]<br />
<br />
== Belgium: Belgian Bitcoin Association ==<br />
* Directors:<br />
** [[Arne Brutschy]]<br />
** [[Chris D'Costa]]<br />
** [[Jérémie Dubois-Lacoste]]<br />
** [[Filip Roose]]<br />
** [[Thomas Spaas]] <br />
** [[Jean Wallemacq]]<br />
<br />
== Canada: The Bitcoin Embassy ==<br />
* [http://bitcoinembassy.ca website]<br />
A non-profit organization seeking to promote the adoption of Bitcoin and related crypto-technologies, as well as facilitating networking throughout the Bitcoin community in Canada and worldwide.<br />
<br />
== Denmark: The Bitcoin Association of Denmark ==<br />
* [http://www.danskbitcoinforening.dk/ Website]<br />
<br />
== Germany: Bundesverband Bitcoin e.V. ==<br />
* [http://www.bundesverband-bitcoin.de/ Website]<br />
* Board members:<br />
** [[Radoslav Albrecht]]<br />
** [[Dennis Daiber]]<br />
** [[Oliver Flaskämper]]<br />
** [[JF Gallas]] Chairman<br />
** [[Timo Hanke]]<br />
** [[Jörg von Minckwitz]]<br />
** [[Jörg Platzer]] Vice Chairman<br />
<br />
== India: Bitcoin Alliance of India ==<br />
* [http://www.bitcoinalliance.in/ Website]<br />
<br />
== Ireland: Bitcoin Foundation of Ireland. ==<br />
* [http://www.bitcoinirl.ie Website]<br />
* Board members:<br />
** [[Alan Donohoe]]<br />
** [[Vincent O Donoghue]]<br />
** [[Roger Ver]]<br />
<br />
<br />
== Israel: איגוד הביטקוין הישראלי ==<br />
See [[The Israeli Bitcoin Association]].<br />
<br />
== Italy: Bitcoin Foundation Italia ==<br />
* [https://www.bitcoin-italia.org/ Website]<br />
* Board members:<br />
** [[Andrea Medri]]<br />
** [[Davide Barbieri]]<br />
** [[Franco Cimatti]]<br />
<br />
== Netherlands: Stichting Bitcoin Nederland ==<br />
* [http://stichtingbitcoin.nl/ Website]<br />
* [http://stichtingbitcoin.nl/index.php/de-stichting/het-bestuur/ Board members]:<br />
** [[Mark van Cuijk]]<br />
** [[Jouke Hofman]]<br />
** [[Richard Kohl]]<br />
** [[Carl Kuntze]]<br />
** [[Sicco Steenhuisen]] Chairman<br />
<br />
== Sweden: The Bitcoin Association of Sweden ==<br />
* [http://www.bitcoinforeningen.se/ Website]<br />
<br />
== Switzerland: Bitcoin Association Switzerland ==<br />
* [http://www.bitcoinassociation.ch/ Website]<br />
* Board members:<br />
** [[Johann Gevers]] - Treasurer<br />
** [[Stefan Greiner]] - Secretary<br />
** [[Luzius Meisser]] - President<br />
<br />
== United Kingdom: UK Bitcoin Foundation ==<br />
* [[Adam Cleary]]<br />
* [[Paul Gordon]]<br />
* [[Eitan Jankelewitz]]<br />
* [[Tom Robinson]]<br />
* [[James Smith]]<br />
* [[Lee Welham]]<br />
<br />
== United States / International: Bitcoin Foundation ==<br />
* [http://bitcoinfoundation.org/ website]<br />
* [https://bitcoinfoundation.org/about/board Board members (alphabetically)]:<br />
** [[Gavin Andresen]] - Chief Scientist<br />
** [[Mark Karpeles]] - Board Member<br />
** [[Micky Malka]] - Board Member<br />
** [[Jon Matonis]] - Executive Director and Board Member<br />
** [[Patrick Murck]] - General Counsel<br />
** [[Elizabeth T. Ploshay]] - Board Member<br />
** [[Peter Vessenes]] - Chairman of the Board<br />
<br />
= Other =<br />
== Bitcoin100 ==<br />
[http://bitcoin100.org/ Bitcoin100] is a charity organization that exists specifically to convince new charities to start accepting bitcoin donations.<br />
<br />
== The Mastercoin Foundation ==<br />
See [http://wiki.mastercoin.org/index.php/The_Mastercoin_Foundation the Mastercoin wiki].<br />
<br />
== PikaPay Foundation ==<br />
<br />
The [https://PikaPay.com PikaPay Foundation] is a nonprofit dedicated to innovation in today’s financial systems and is focussed on developing the Bitcoin ecosystem.<br />
<br />
PikaPay's Mission: To explore trends in science, technology, community and culture; To overcome limitations of traditional financial services; To improve lives, empower groups and individuals; and To make greater social contributions to the world.<br />
<br />
= See Also =<br />
# [https://bitcointalk.org/index.php?topic=288677.0 bitcointalk thread]<br />
# [https://docs.google.com/document/d/1TnTCcT7fiNr5nt-oApr_7DwXAypFoJpZ6lk_w_ykwcc/edit google doc].<br />
# [[:Category:nonprofit]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=List_of_Bitcoin_non-profits_around_the_world&diff=43132List of Bitcoin non-profits around the world2013-12-14T00:24:22Z<p>XertroV: /* United States / International: Bitcoin Foundation */ Added Mickey and Elizabeth</p>
<hr />
<div>This page will list all the known Bitcoin and crypto-currency non-profits around the world. The criterias for being on this list are:<br />
<br />
# A focus on Bitcoin or crypto-currency (merely accepting Bitcoin donations is not enough)<br />
# Being a non-profit<br />
# The organization needs to be either a registered non-profit or in the process of active registration.<br />
<br />
= List of organizations (by country of residence)=<br />
== Australia: The Bitcoin Association of Australia ==<br />
* Board members:<br />
** [[Martin Bajalan]]<br />
** [[Max Kaye]] Treasurer<br />
** [[Adam Poulton]] Secretary<br />
** [[Pantelis Roussakis]] Vice-President<br />
** [[Bret Treasure]]<br />
** [[Jason Williams]] President<br />
** [[Tristan Winters]]<br />
<br />
== Austria: Bitcoin Austria ==<br />
* [http://bitcoin-austria.at/ Website]<br />
<br />
== Belgium: Belgian Bitcoin Association ==<br />
* Directors:<br />
** [[Arne Brutschy]]<br />
** [[Chris D'Costa]]<br />
** [[Jérémie Dubois-Lacoste]]<br />
** [[Filip Roose]]<br />
** [[Thomas Spaas]] <br />
** [[Jean Wallemacq]]<br />
<br />
== Canada: The Bitcoin Embassy ==<br />
* [http://bitcoinembassy.ca website]<br />
A non-profit organization seeking to promote the adoption of Bitcoin and related crypto-technologies, as well as facilitating networking throughout the Bitcoin community in Canada and worldwide.<br />
<br />
== Germany: Bundesverband Bitcoin e.V. ==<br />
* [http://www.bundesverband-bitcoin.de/ Website]<br />
* Board members:<br />
** [[Radoslav Albrecht]]<br />
** [[Dennis Daiber]]<br />
** [[Oliver Flaskämper]]<br />
** [[JF Gallas]] Chairman<br />
** [[Timo Hanke]]<br />
** [[Jörg von Minckwitz]]<br />
** [[Jörg Platzer]] Vice Chairman<br />
<br />
== Israel: איגוד הביטקוין הישראלי ==<br />
See [[The Israeli Bitcoin Association]].<br />
<br />
== Italy: Bitcoin Foundation Italia ==<br />
* [https://www.bitcoin-italia.org/ Website]<br />
* Board members:<br />
** [[Andrea Medri]]<br />
** [[Davide Barbieri]]<br />
** [[Franco Cimatti]]<br />
<br />
== Netherlands: Stichting Bitcoin Nederland ==<br />
* [http://stichtingbitcoin.nl/ Website]<br />
* [http://stichtingbitcoin.nl/index.php/de-stichting/het-bestuur/ Board members]:<br />
** [[Mark van Cuijk]]<br />
** [[Jouke Hofman]]<br />
** [[Richard Kohl]]<br />
** [[Carl Kuntze]]<br />
** [[Sicco Steenhuisen]] Chairman<br />
<br />
== Switzerland: Bitcoin Association Switzerland ==<br />
* [http://www.bitcoinassociation.ch/ Website]<br />
* Board members:<br />
** [[Johann Gevers]] - Treasurer<br />
** [[Stefan Greiner]] - Secretary<br />
** [[Luzius Meisser]] - President<br />
<br />
== United Kingdom: UK Bitcoin Foundation ==<br />
* [[Adam Cleary]]<br />
* [[Paul Gordon]]<br />
* [[Eitan Jankelewitz]]<br />
* [[Tom Robinson]]<br />
* [[James Smith]]<br />
* [[Lee Welham]]<br />
<br />
== United States / International: Bitcoin Foundation ==<br />
* [http://bitcoinfoundation.org/ website]<br />
* [https://bitcoinfoundation.org/about/board Board members (alphabetically)]:<br />
** [[Gavin Andresen]] - Chief Scientist<br />
** [[Mark Karpeles]] - Board Member<br />
** [[Micky Malka]] - Board Member<br />
** [[Jon Matonis]] - Executive Director and Board Member<br />
** [[Patrick Murck]] - General Counsel<br />
** [[Elizabeth T. Ploshay]] - Board Member<br />
** [[Charlie Shrem]] - Vice Chairman<br />
** [[Peter Vessenes]] - Chairman of the Board<br />
<br />
= Other =<br />
== Bitcoin100 ==<br />
[http://bitcoin100.org/ Bitcoin100] is a charity organization that exists specifically to convince new charities to start accepting bitcoin donations.<br />
<br />
== The Mastercoin Foundation ==<br />
See [http://wiki.mastercoin.org/index.php/The_Mastercoin_Foundation the Mastercoin wiki].<br />
<br />
== PikaPay Foundation ==<br />
<br />
The [https://PikaPay.com PikaPay Foundation] is a nonprofit dedicated to innovation in today’s financial systems and is focussed on developing the Bitcoin ecosystem.<br />
<br />
PikaPay's Mission: To explore trends in science, technology, community and culture; To overcome limitations of traditional financial services; To improve lives, empower groups and individuals; and To make greater social contributions to the world.<br />
<br />
= See Also =<br />
# [https://bitcointalk.org/index.php?topic=288677.0 bitcointalk thread]<br />
# [https://docs.google.com/document/d/1TnTCcT7fiNr5nt-oApr_7DwXAypFoJpZ6lk_w_ykwcc/edit google doc].<br />
# [[:Category:nonprofit]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=Contract&diff=41291Contract2013-09-25T04:37:39Z<p>XertroV: /* Example 5: Trading across chains */ added missing SHA256 in scriptpubkey for chain trade; both secrets have to be hashed separately before EQUALVERIFY</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
As of May 2013 work on implementing this protocol has begun. Please contact Mike if you would like to work on this, so you can be put in touch with the people who are already implementing it.<br />
<br />
===Minimizing trust in the oracle===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. <br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
Cryptographers have recently been making excellent progress in the field of '''verifiable computation'''. This allows an untrusted server to execute a pure function in which some inputs can be private, and produce a proof that it was executed correctly. If the oracle program can be expressed as a pure function, then this technique can be powerfully applied. However there are performance limits. The current state of the art as of summer 2013 is [http://research.microsoft.com/pubs/180286/pinocchio.pdf Pinnochio], an open source system from Microsoft Research. For some classes of functions checking the proof can be faster than executing the program itself, for others it is still slower - however, quite within the realms of feasibility. Because the programs are pure functions, they cannot do any I/O, therefore no access to the internet. This is quite restrictive as often the point of an oracle program is to measure external state. We can work around this restriction by providing signed data to the program and have the program itself check the signatures - to make it as easy as possible to get signed data from as many sources as possible, an extension to the SSL/TLS protocol that allows for signing of arbitrary sessions may be appropriate.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. However, because distinct blockchains have different views of time, currently known proposals are susceptible to either a) a loss of funds if one party fails to complete the protocol; or, b) if timeouts are used, a race condition whereby one party could take all the funds. [https://bitcointalk.org/index.php?topic=91843 This was first pointed out] by Sergio Demian-Lerner, who proposed a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY SHA256 <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details and alternative implementations.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=Block_hashing_algorithm&diff=38873Block hashing algorithm2013-06-24T10:18:02Z<p>XertroV: Updated pastebin contents to compile correctly without warnings.</p>
<hr />
<div>When generating, you constantly hash the block header. The block is also occasionally updated as you are working on it. A block header contains these fields:<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Purpose<br />
! Updated when...<br />
! Size (Bytes)<br />
|-<br />
|Version<br />
|Block version number<br />
|You upgrade the software and it specifies a new version<br />
|4<br />
|-<br />
|hashPrevBlock<br />
|256-bit hash of the previous block header<br />
|A new block comes in<br />
|32<br />
|-<br />
|hashMerkleRoot<br />
|256-bit hash based on all of the transactions in the block<br />
|A transaction is accepted<br />
|32<br />
|-<br />
|Time<br />
|Current timestamp as seconds since 1970-01-01T00:00 UTC<br />
|Every few seconds<br />
|4<br />
|-<br />
|Bits<br />
|Current [[target]] in compact format<br />
|The [[difficulty]] is adjusted<br />
|4<br />
|-<br />
|Nonce<br />
|32-bit number (starts at 0)<br />
|A hash is tried (increments)<br />
|4<br />
|}<br />
<br />
The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.<br />
<br />
The compact format of target is a special kind of floating-point encoding using 3 bytes mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256.<br />
Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. "Nonce" starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.<br />
<br />
Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win. However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of ''your'' unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.<br />
<br />
Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.<br />
<br />
For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, [http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d Block 125552]. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:<br />
<br />
>>> import hashlib<br />
>>> header_hex = ("01000000" +<br />
"81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +<br />
"e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +<br />
"c7f5d74d" +<br />
"f2b9441a" +<br />
"42a14695")<br />
>>> header_bin = header_hex.decode('hex')<br />
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()<br />
>>> hash.encode('hex_codec')<br />
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'<br />
>>> hash[::-1].encode('hex_codec')<br />
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'<br />
<br />
Note that the actual hash, which is a 256-bit number, has lots of leading zero bits. When stored or printed as a big-endian hexadecimal constant, but it has leading zero bytes and if stored or printed as little-endian, these are the trailing zero bytes. E.g. if interpretation as a string -- lowest (or start of) string address keeps lowest significant byte, thus little-endian.<br />
The output of [http://blockexplorer.com blockexplorer] displays the hash values as big-endians numbers as notation for numbers is usual -- leading digits are the most significant digits read from left to right.<br />
<br />
For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.<br />
<br />
[[Category:Technical]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=Merged_mining_specification&diff=38827Merged mining specification2013-06-21T07:38:15Z<p>XertroV: 'thus', not 'thusly'</p>
<hr />
<div>NOTE: This standard is used by [[Namecoin]], but new merged mining data should likely propose a new BIP to supercede it with something based on p2pool's merged mining.<br />
<br />
== Terminology ==<br />
;Auxiliary Proof-of-Work (POW): a.k.a "AuxPOW". This is the way that merged mining can exist; it is the relationship between two blockchains for one to trust the other's work as their own and accept AuxPOW blocks.<br />
;Merged Mining: The act of using work done on one blockchain on more than one chain, using Auxiliary POW.<br />
----<br />
;Auxiliary Blockchain: The altcoin that is accepting work done on alternate chains as valid on its own chain. Client applications have to be modified to accept Auxiliary POW.<br />
;Parent Blockchain: The blockchain where the actual mining work is taking place. This chain does not need to be aware of the Auxiliary POW logic, as AuxPOW blocks submitted to this chain are still valid blocks.<br />
----<br />
;Parent Block: Not to be confused with the "previous block". This is a block that is structured for the parent blockchain (i.e. the <tt>prev_block</tt> hash points to the prior block on the parent blockchain). The header of this block is part of the AuxPOW Block in the auxiliary blockchain.<br />
;AuxPOW Block: This is a new type of block that is similar to a standard blockchain block, with two important differences. Firstly, the hash of the block header does NOT meet the difficulty level of the blockchain (so, if interpreted by a naive client, will be thrown out as not meeting the difficulty level). Secondly, it has additional data elements that show that the miner who created this block actually did mining activity (hashing) on the parent blockchain, and that work meets the difficulty level of the auxiliary blockchain, which is why this block should be accepted.<br />
<br />
== Aux proof-of-work block ==<br />
This is used to prove work on the auxiliary blockchain. In vinced's original implementation it's generated by calling the <tt>getworkaux</tt> RPC method on the parent blockchain client (<tt>bitcoind</tt>) and then the work is then submitted by passing it to the auxiliary chain client (<tt>namecoind</tt>) as the second parameter to <tt>getauxblock</tt>.<br />
<br />
When receiving an Aux proof-of-work block in a [[Protocol specification#block|"<tt>block</tt>" network message]], the data received is similar to a standard block, but extra data is inserted between the <tt>nonce</tt> and <tt>txn_count</tt> elements. In the below table, the shaded rows are the same as the standard block definition:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || version || uint32_t ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 32 || prev_block || char[32] ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 32 || merkle_root || char[32] ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || timestamp || uint32_t ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || bits || uint32_t ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || nonce || uint32_t ||<br />
|-<br />
| ? || coinbase_txn || [[Protocol specification#tx|txn]] || Coinbase transaction that is in the parent block, [[#Merged mining coinbase|linking]] the AuxPOW block to its parent block<br />
|-<br />
| 32 || block_hash || char[32] || Hash of the <tt>parent_block</tt> header<br />
|-<br />
| ? || coinbase_branch || [[#Merkle Branch|Merkle branch]] || The merkle branch linking the <tt>coinbase_txn</tt> to the parent block's <tt>merkle_root</tt><br />
|-<br />
| ? || blockchain_branch || [[#Merkle Branch|Merkle branch]] || The merkle branch linking this auxiliary blockchain to the others, when used in a merged mining setup with multiple auxiliary chains<br />
|-<br />
| 80 || parent_block || [[Protocol specification#block|Block header]] || Parent block header<br />
|- style="background-color:#DDD; color:#999;"<br />
| ? || txn_count || var_int || <br />
|- style="background-color:#DDD; color:#999;"<br />
| ? || txns || tx[] || <br />
|}<br />
<br />
For the <tt>coinbase_branch</tt> merkle branch, because the coinbase transaction is the first transaction in the block (if using Bitcoin as a parent chain, i.e. hash #7 in the example given [[#Merkle Branch|below]]), the <tt>branch_side_mask</tt> is always going to be all zeroes, because the branch hashes will always be "on the right" of the working hash.<br />
<br />
When only working on one auxiliary blockchain, the <tt>blockchain_branch</tt> link is not needed, and is nulled-out by being presented as 5 bytes of zeros (interpreted as a one-byte <tt>var_int</tt> indicating a <tt>branch_length</tt> of zero, and a 32-bit (4 byte) <tt>branch_side_mask</tt> of all zeroes).<br />
<br />
Note that the <tt>block_hash</tt> element is not needed as you have the full <tt>parent_block</tt> header element and can calculate the hash from that. The current Namecoin client doesn't check this field for validity, and as such some AuxPOW blocks have it little-endian, and some have it big-endian.<br />
<br />
== Merkle Branch ==<br />
Say Alice created a Merkle tree, and it's root element is publicly available. For example:<br />
<br />
<pre><br />
merkleRoot (0)<br />
/ \<br />
/ \<br />
1 2<br />
/ \ / \<br />
/ \ / \<br />
3 4 5 6<br />
/ \ / \ / \ / \<br />
7 8 9 10 11 12 13 14<br />
</pre><br />
<br />
Now she wants to prove to Bob that a given hash (#10) was part of that tree, but Bob doesn't have the full tree (only the public root; hash #0). Alice can send Bob all the hashes she used to make the tree in the first place (hashes #7-#14, total of 7 extra hashes), so Bob can build the whole tree to verify the root is the same, but that's rather data-intensive. Instead, she could give Bob hashes #9, #3, and #2 (one from each level of the tree, working #10 back to the root). Without Bob knowing the structure of the tree, Alice also has to tell Bob what order to apply the hashes in (since <tt>hash(#9, #10) == #4</tt>, but <tt>hash(#10, #9) != #4</tt>). So Alice tells Bob "left, left, right" to indicate which operand #9, #3, and #2 are, respectively. That can be encoded as a bitmask and take up very little data to transmit. So, instead of transmitting 7 hashes to Bob, Alice transmits 3 hashes and a bitmask. The data savings get even more pronounced if the merkle tree gets even bigger.<br />
<br />
That is the overall premise, and specifically for the AuxPOW protocol, it's been termed a "merkle branch" (since it's one pathway of a merkle tree), and is transmitted thus:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || branch_length || [[Protocol_specification#Variable_length_integer|var_int]] || The number of hashes making up the branch<br />
|-<br />
| ? || branch_hash[] || char[32] || Individual hash in the branch; repeated <tt>branch_length</tt> number of times<br />
|-<br />
| 4 || branch_side_mask || int32_t || Bitmask of which side of the merkle hash function the <tt>branch_hash</tt> element should go on. Zero means it goes on the right, One means on the left.<br />
|}<br />
<br />
The first <tt>branch_hash</tt> is used first, and the least-significant bit of the <tt>branch_side_mask</tt> determines its hash position. Then the second <tt>branch_hash</tt> is applied with the second-least-significant bit of the <tt>branch_side_mask</tt>, etc. So for Alice's example, <tt>branch_length</tt> would be 3, the hashes would be given in the order #9, #3, then #2, and the <tt>branch_side_mask</tt> would be <tt>0b011</tt> = 3.<br />
<br />
== Merged mining coinbase ==<br />
Insert exactly one of these headers into the <tt>scriptSig</tt> of the coinbase transaction in the parent block.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || char[4] || <tt>0xfa</tt>, <tt>0xbe</tt>, 'm', 'm' '''(only required if over 20 bytes past the start of the script; optional otherwise)'''<br />
|-<br />
| 32 || block_hash || char[32] || Hash of the AuxPOW block header<br />
|-<br />
| 4 || merkle_size || int32_t || Number of entries in aux work merkle tree. '''(Must be a power of 2)'''<br />
|-<br />
| 4 || merkle_nonce || int32_t || Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero<br />
|}<br />
<br />
That string of 44 bytes being part of the coinbase script means that the miner constructed the AuxPOW Block before creating the coinbase.<br />
<br />
==Aux work merkle tree==<br />
If you're just mining a single auxiliary chain and using getauxblock, you don't have to worry about this - just set the merkle tree hash in the coinbase to the aux chain block's hash as given by getauxblock, the merkle size to 1, and the merkle nonce to 0. If you're mining more than one, this is a bit broken. It uses the following algorithm to convert the chain ID to a slot at the base of the merkle tree in which that chain's block hash must slot:<br />
<br />
<pre>unsigned int rand = merkle_nonce;<br />
rand = rand * 1103515245 + 12345;<br />
rand += chain_id;<br />
rand = rand * 1103515245 + 12345;<br />
slot_num = rand % merkle_size</pre><br />
<br />
The idea is that you can increment merkle_nonce until the chains you're mining don't clash for the same slot. The trouble is that this doesn't work; because it just adds a number derived from the merkle_nonce to the chain_id, if two chains clash for one nonce they'll still clash for all possible nonces.<ref>https://bitcointalk.org/index.php?topic=51069.0</ref> New implementers: please pick your chain_id so that not clashing with existing chains requires as small a value of merkle_size as possible, or use a better algorithm to calculate the slot id for your chain.<br />
<br />
Once you know where in the merkle tree the different chains go, ''reverse the bytes of each chain's block hash as given you by getauxblock'' (so the byte at the start moves to the end, etc) and insert into the appropriate slot, filling the unused ones with arbitrary data. Now build up the merkle tree as usual by taking each pair of values in the initial row and double SHA-256 hashing them to give a new row of hashes, repeating this until you only have a single hash. This last hash is the merkle root. You need to ''reverse the bytes of this again'' before inserting it into the coinbase. If you're not using getauxblock to get the block hash, you can skip the first reversal but still need to reverse the final merkle root when adding it to the coinbase.<br />
<br />
The aux proof-of-work also needs a merkle branch, which is built as follows: find the location of the block's hash in the merkle tree, and add the other value that you hashed it with in building the merkle tree. Now add the value you hashed that result with. Keep doing this until you reach the root. The merkle root itself is ''never'' included in the merkle branch. If you just have a single aux chain, this can be left entirely empty. (It also appears you ''don't'' need to reverse these hashes.)<br />
<br />
== Example ==<br />
This is the AuxPOW block at [http://explorer.dot-bit.org/b/19200 height 19200] in the Namecoin chain (the first block that allowed AuxPOW authentication). It has a hash of <tt>d8a7c3e01e1e95bcee015e6fcc7583a2ca60b79e5a3aa0a171eddd344ada903d</tt>, and only has one Namecoin transaction (coinbase sending 50 NMC to the miner's address). The parent block that was used as Proof of Work has a hash less than the difficulty target of Namecoin at the time, but not the Bitcoin target:<br />
<pre><br />
0000000000003d47277359fb969c43e3c7e7c0306a17f6444b8e91e19def03a9 -- parent block hash<br />
000000000000b269000000000000000000000000000000000000000000000000 -- Namecoin difficulty target<br />
00000000000009ee5d0000000000000000000000000000000000000000000000 -- Bitcoin difficulty target<br />
</pre><br />
<br />
Hence, this AuxPOW block was valid in the Namecoin blockchain, but not in the Bitcoin blockchain (you will find no Bitcoin block with the hash starting <tt>3d47277359fb969c</tt>. If it were, it would be right after [https://blockchain.info/block-index/163650/00000000000004a59b7deb5c4e01b9786ea01ee8da000db77ce6035c2913be08 <tt>4a59b7deb5c4e01b</tt>], since that's the <tt>previous_block</tt> hash used)<br />
<br />
<pre><br />
Block Header:<br />
01 01 01 00 // Version<br />
36 90 9a c0 7a 16 73 da f6 5f a7 d8 28 88 2e 66 c9 e8 9f 85 46 cd d5 0a 9f b1 00 00 00 00 00 00 // Previous block hash<br />
0f 5c 65 49 bc d6 08 ab 7c 4e ac 59 3e 5b d5 a7 3b 2d 43 2e b6 35 18 70 8f 77 8f c7 dc df af 88 // Merkle root<br />
8d 1a 90 4e // Timestamp<br />
69 b2 00 1b // Bits<br />
00 00 00 00 // Nonce<br />
<br />
Parent Block Coinbase Transaction:<br />
01 00 00 00 // Version<br />
01 // TxIn Count<br />
<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // Previous Out<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff<br />
<br />
35 // Script size<br />
04 5d ee 09 1a 01 4d 52 2c fa be 6d 6d d8 a7 c3 e0 1e 1e 95 bc ee 01 5e 6f cc 75 83 a2 ca 60 b7 // Script<br />
9e 5a 3a a0 a1 71 ed dd 34 4a da 90 3d 01 00 00 00 00 00 00 00<br />
<br />
ff ff ff ff // Sequence Number<br />
01 // TxOut Count<br />
60 a0 10 2a 01 00 00 00 // Amount<br />
<br />
43 // Script Size<br />
41 04 f8 bb e9 7e d2 ac bc 5b ba 11 c6 8f 6f 1a 03 13 f9 18 f3 d3 c0 e8 47 50 55 e3 51 e3 bf 44 // Script<br />
2f 8c 8d ce e6 82 d2 45 7b dc 53 51 b7 0d d9 e3 40 26 76 6e ba 18 b0 6e ae e2 e1 02 ef d1 ab 63<br />
46 67 ac<br />
<br />
00 00 00 00 // Lock Time<br />
<br />
Coinbase Link:<br />
a9 03 ef 9d e1 91 8e 4b 44 f6 17 6a 30 c0 e7 c7 e3 43 9c 96 fb 59 73 27 47 3d 00 00 00 00 00 00 // Hash of parent block header<br />
05 // Number of links in branch<br />
05 0a c4 a1 a1 e1 bc e0 c4 8e 55 5b 1a 9f 93 52 81 96 8c 72 d6 37 9b 24 72 9c a0 42 5a 3f c3 cb // Hash #1<br />
43 3c d3 48 b3 5e a2 28 06 cf 21 c7 b1 46 48 9a ef 69 89 55 1e b5 ad 23 73 ab 61 21 06 0f 30 34 // Hash #2<br />
1d 64 87 57 c0 21 7d 43 e6 6c 57 ea ed 64 fc 18 20 ec 65 d1 57 f3 3b 74 19 65 18 3a 5e 0c 85 06 // Hash #3<br />
ac 26 02 df e2 f5 47 01 2d 1c c7 50 04 d4 8f 97 ab a4 6b d9 93 0f f2 85 c9 f2 76 f5 bd 09 f3 56 // Hash #4<br />
df 19 72 45 79 d6 5e c7 cb 62 bf 97 94 6d fc 6f b0 e3 b2 83 9b 7f da b3 7c db 60 e5 51 22 d3 5b // Hash #5<br />
00 00 00 00 // Branch sides bitmask<br />
<br />
Aux Blockchain Link:<br />
00 // Number of links in branch<br />
00 00 00 00 // Branch sides bitmask<br />
<br />
Parent Block Header:<br />
01 00 00 00 // Version<br />
08 be 13 29 5c 03 e6 7c b7 0d 00 da e8 1e a0 6e 78 b9 01 4e 5c eb 7d 9b a5 04 00 00 00 00 00 00 // Previous block hash<br />
e0 fd 42 db 8e f6 d7 83 f0 79 d1 26 be a1 2e 2d 10 c1 04 c0 92 7c d6 8f 95 4d 85 6f 9e 81 11 e5 // Merkle root<br />
9a 23 90 4e // Timestamp<br />
5d ee 09 1a // Bits<br />
1c 65 50 86 // Nonce<br />
<br />
Transactions:<br />
01 // Tx Count<br />
01 00 00 00 // Version<br />
01 // TxIn Count<br />
<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // Previous Out<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff<br />
<br />
08 // Script size<br />
04 69 b2 00 1b 01 01 52 // Script<br />
ff ff ff ff // Sequence number<br />
01 // TxOut Count<br />
00 f2 05 2a 01 00 00 00 // Amount<br />
<br />
43 // Script size<br />
41 04 89 fe 91 e6 28 47 57 5c 98 de ea b0 20 f6 5f df f1 7a 3a 87 0e bb 05 82 0b 41 4f 3d 80 97 // Script<br />
21 8e c9 a6 5f 1e 0a e0 ac 35 af 72 47 bd 79 ed 1f 2a 24 67 5f ff b5 aa 6f 96 20 e1 92 0a d4 bf<br />
5a a6 ac<br />
<br />
00 00 00 00 // Lock Time<br />
</pre><br />
<br />
==Notes==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>XertroVhttps://en.bitcoin.it/w/index.php?title=Merged_mining_specification&diff=38810Merged mining specification2013-06-20T09:00:28Z<p>XertroV: Added to Technical and Developer categories</p>
<hr />
<div>NOTE: This standard is used by [[Namecoin]], but new merged mining data should likely propose a new BIP to supercede it with something based on p2pool's merged mining.<br />
<br />
== Terminology ==<br />
;Auxiliary Proof-of-Work (POW): a.k.a "AuxPOW". This is the way that merged mining can exist; it is the relationship between two blockchains for one to trust the other's work as their own and accept AuxPOW blocks.<br />
;Merged Mining: The act of using work done on one blockchain on more than one chain, using Auxiliary POW.<br />
----<br />
;Auxiliary Blockchain: The altcoin that is accepting work done on alternate chains as valid on its own chain. Client applications have to be modified to accept Auxiliary POW.<br />
;Parent Blockchain: The blockchain where the actual mining work is taking place. This chain does not need to be aware of the Auxiliary POW logic, as AuxPOW blocks submitted to this chain are still valid blocks.<br />
----<br />
;Parent Block: Not to be confused with the "previous block". This is a block that is structured for the parent blockchain (i.e. the <tt>prev_block</tt> hash points to the prior block on the parent blockchain). The header of this block is part of the AuxPOW Block in the auxiliary blockchain.<br />
;AuxPOW Block: This is a new type of block that is similar to a standard blockchain block, with two important differences. Firstly, the hash of the block header does NOT meet the difficulty level of the blockchain (so, if interpreted by a naive client, will be thrown out as not meeting the difficulty level). Secondly, it has additional data elements that show that the miner who created this block actually did mining activity (hashing) on the parent blockchain, and that work meets the difficulty level of the auxiliary blockchain, which is why this block should be accepted.<br />
<br />
== Aux proof-of-work block ==<br />
This is used to prove work on the auxiliary blockchain. In vinced's original implementation it's generated by calling the <tt>getworkaux</tt> RPC method on the parent blockchain client (<tt>bitcoind</tt>) and then the work is then submitted by passing it to the auxiliary chain client (<tt>namecoind</tt>) as the second parameter to <tt>getauxblock</tt>.<br />
<br />
When receiving an Aux proof-of-work block in a [[Protocol specification#block|"<tt>block</tt>" network message]], the data received is similar to a standard block, but extra data is inserted between the <tt>nonce</tt> and <tt>txn_count</tt> elements. In the below table, the shaded rows are the same as the standard block definition:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || version || uint32_t ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 32 || prev_block || char[32] ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 32 || merkle_root || char[32] ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || timestamp || uint32_t ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || bits || uint32_t ||<br />
|- style="background-color:#DDD; color:#999;"<br />
| 4 || nonce || uint32_t ||<br />
|-<br />
| ? || coinbase_txn || [[Protocol specification#tx|txn]] || Coinbase transaction that is in the parent block, [[#Merged mining coinbase|linking]] the AuxPOW block to its parent block<br />
|-<br />
| 32 || block_hash || char[32] || Hash of the <tt>parent_block</tt> header<br />
|-<br />
| ? || coinbase_branch || [[#Merkle Branch|Merkle branch]] || The merkle branch linking the <tt>coinbase_txn</tt> to the parent block's <tt>merkle_root</tt><br />
|-<br />
| ? || blockchain_branch || [[#Merkle Branch|Merkle branch]] || The merkle branch linking this auxiliary blockchain to the others, when used in a merged mining setup with multiple auxiliary chains<br />
|-<br />
| 80 || parent_block || [[Protocol specification#block|Block header]] || Parent block header<br />
|- style="background-color:#DDD; color:#999;"<br />
| ? || txn_count || var_int || <br />
|- style="background-color:#DDD; color:#999;"<br />
| ? || txns || tx[] || <br />
|}<br />
<br />
For the <tt>coinbase_branch</tt> merkle branch, because the coinbase transaction is the first transaction in the block (if using Bitcoin as a parent chain, i.e. hash #7 in the example given [[#Merkle Branch|below]]), the <tt>branch_side_mask</tt> is always going to be all zeroes, because the branch hashes will always be "on the right" of the working hash.<br />
<br />
When only working on one auxiliary blockchain, the <tt>blockchain_branch</tt> link is not needed, and is nulled-out by being presented as 5 bytes of zeros (interpreted as a one-byte <tt>var_int</tt> indicating a <tt>branch_length</tt> of zero, and a 32-bit (4 byte) <tt>branch_side_mask</tt> of all zeroes).<br />
<br />
Note that the <tt>block_hash</tt> element is not needed as you have the full <tt>parent_block</tt> header element and can calculate the hash from that. The current Namecoin client doesn't check this field for validity, and as such some AuxPOW blocks have it little-endian, and some have it big-endian.<br />
<br />
== Merkle Branch ==<br />
Say Alice created a Merkle tree, and it's root element is publicly available. For example:<br />
<br />
<pre><br />
merkleRoot (0)<br />
/ \<br />
/ \<br />
1 2<br />
/ \ / \<br />
/ \ / \<br />
3 4 5 6<br />
/ \ / \ / \ / \<br />
7 8 9 10 11 12 13 14<br />
</pre><br />
<br />
Now she wants to prove to Bob that a given hash (#10) was part of that tree, but Bob doesn't have the full tree (only the public root; hash #0). Alice can send Bob all the hashes she used to make the tree in the first place (hashes #7-#14, total of 7 extra hashes), so Bob can build the whole tree to verify the root is the same, but that's rather data-intensive. Instead, she could give Bob hashes #9, #3, and #2 (one from each level of the tree, working #10 back to the root). Without Bob knowing the structure of the tree, Alice also has to tell Bob what order to apply the hashes in (since <tt>hash(#9, #10) == #4</tt>, but <tt>hash(#10, #9) != #4</tt>). So Alice tells Bob "left, left, right" to indicate which operand #9, #3, and #2 are, respectively. That can be encoded as a bitmask and take up very little data to transmit. So, instead of transmitting 7 hashes to Bob, Alice transmits 3 hashes and a bitmask. The data savings get even more pronounced if the merkle tree gets even bigger.<br />
<br />
That is the overall premise, and specifically for the AuxPOW protocol, it's been termed a "merkle branch" (since it's one pathway of a merkle tree), and is transmitted thusly:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || branch_length || [[Protocol_specification#Variable_length_integer|var_int]] || The number of hashes making up the branch<br />
|-<br />
| ? || branch_hash[] || char[32] || Individual hash in the branch; repeated <tt>branch_length</tt> number of times<br />
|-<br />
| 4 || branch_side_mask || int32_t || Bitmask of which side of the merkle hash function the <tt>branch_hash</tt> element should go on. Zero means it goes on the right, One means on the left.<br />
|}<br />
<br />
The first <tt>branch_hash</tt> is used first, and the least-significant bit of the <tt>branch_side_mask</tt> determines its hash position. Then the second <tt>branch_hash</tt> is applied with the second-least-significant bit of the <tt>branch_side_mask</tt>, etc. So for Alice's example, <tt>branch_length</tt> would be 3, the hashes would be given in the order #9, #3, then #2, and the <tt>branch_side_mask</tt> would be <tt>0b011</tt> = 3.<br />
<br />
== Merged mining coinbase ==<br />
Insert exactly one of these headers into the <tt>scriptSig</tt> of the coinbase transaction in the parent block.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || char[4] || <tt>0xfa</tt>, <tt>0xbe</tt>, 'm', 'm' '''(only required if over 20 bytes past the start of the script; optional otherwise)'''<br />
|-<br />
| 32 || block_hash || char[32] || Hash of the AuxPOW block header<br />
|-<br />
| 4 || merkle_size || int32_t || Number of entries in aux work merkle tree. '''(Must be a power of 2)'''<br />
|-<br />
| 4 || merkle_nonce || int32_t || Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero<br />
|}<br />
<br />
That string of 44 bytes being part of the coinbase script means that the miner constructed the AuxPOW Block before creating the coinbase.<br />
<br />
==Aux work merkle tree==<br />
If you're just mining a single auxiliary chain and using getauxblock, you don't have to worry about this - just set the merkle tree hash in the coinbase to the aux chain block's hash as given by getauxblock, the merkle size to 1, and the merkle nonce to 0. If you're mining more than one, this is a bit broken. It uses the following algorithm to convert the chain ID to a slot at the base of the merkle tree in which that chain's block hash must slot:<br />
<br />
<pre>unsigned int rand = merkle_nonce;<br />
rand = rand * 1103515245 + 12345;<br />
rand += chain_id;<br />
rand = rand * 1103515245 + 12345;<br />
slot_num = rand % merkle_size</pre><br />
<br />
The idea is that you can increment merkle_nonce until the chains you're mining don't clash for the same slot. The trouble is that this doesn't work; because it just adds a number derived from the merkle_nonce to the chain_id, if two chains clash for one nonce they'll still clash for all possible nonces.<ref>https://bitcointalk.org/index.php?topic=51069.0</ref> New implementers: please pick your chain_id so that not clashing with existing chains requires as small a value of merkle_size as possible, or use a better algorithm to calculate the slot id for your chain.<br />
<br />
Once you know where in the merkle tree the different chains go, ''reverse the bytes of each chain's block hash as given you by getauxblock'' (so the byte at the start moves to the end, etc) and insert into the appropriate slot, filling the unused ones with arbitrary data. Now build up the merkle tree as usual by taking each pair of values in the initial row and double SHA-256 hashing them to give a new row of hashes, repeating this until you only have a single hash. This last hash is the merkle root. You need to ''reverse the bytes of this again'' before inserting it into the coinbase. If you're not using getauxblock to get the block hash, you can skip the first reversal but still need to reverse the final merkle root when adding it to the coinbase.<br />
<br />
The aux proof-of-work also needs a merkle branch, which is built as follows: find the location of the block's hash in the merkle tree, and add the other value that you hashed it with in building the merkle tree. Now add the value you hashed that result with. Keep doing this until you reach the root. The merkle root itself is ''never'' included in the merkle branch. If you just have a single aux chain, this can be left entirely empty. (It also appears you ''don't'' need to reverse these hashes.)<br />
<br />
== Example ==<br />
This is the AuxPOW block at [http://explorer.dot-bit.org/b/19200 height 19200] in the Namecoin chain (the first block that allowed AuxPOW authentication). It has a hash of <tt>d8a7c3e01e1e95bcee015e6fcc7583a2ca60b79e5a3aa0a171eddd344ada903d</tt>, and only has one Namecoin transaction (coinbase sending 50 NMC to the miner's address). The parent block that was used as Proof of Work has a hash less than the difficulty target of Namecoin at the time, but not the Bitcoin target:<br />
<pre><br />
0000000000003d47277359fb969c43e3c7e7c0306a17f6444b8e91e19def03a9 -- parent block hash<br />
000000000000b269000000000000000000000000000000000000000000000000 -- Namecoin difficulty target<br />
00000000000009ee5d0000000000000000000000000000000000000000000000 -- Bitcoin difficulty target<br />
</pre><br />
<br />
Hence, this AuxPOW block was valid in the Namecoin blockchain, but not in the Bitcoin blockchain (you will find no Bitcoin block with the hash starting <tt>3d47277359fb969c</tt>. If it were, it would be right after [https://blockchain.info/block-index/163650/00000000000004a59b7deb5c4e01b9786ea01ee8da000db77ce6035c2913be08 <tt>4a59b7deb5c4e01b</tt>], since that's the <tt>previous_block</tt> hash used)<br />
<br />
<pre><br />
Block Header:<br />
01 01 01 00 // Version<br />
36 90 9a c0 7a 16 73 da f6 5f a7 d8 28 88 2e 66 c9 e8 9f 85 46 cd d5 0a 9f b1 00 00 00 00 00 00 // Previous block hash<br />
0f 5c 65 49 bc d6 08 ab 7c 4e ac 59 3e 5b d5 a7 3b 2d 43 2e b6 35 18 70 8f 77 8f c7 dc df af 88 // Merkle root<br />
8d 1a 90 4e // Timestamp<br />
69 b2 00 1b // Bits<br />
00 00 00 00 // Nonce<br />
<br />
Parent Block Coinbase Transaction:<br />
01 00 00 00 // Version<br />
01 // TxIn Count<br />
<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // Previous Out<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff<br />
<br />
35 // Script size<br />
04 5d ee 09 1a 01 4d 52 2c fa be 6d 6d d8 a7 c3 e0 1e 1e 95 bc ee 01 5e 6f cc 75 83 a2 ca 60 b7 // Script<br />
9e 5a 3a a0 a1 71 ed dd 34 4a da 90 3d 01 00 00 00 00 00 00 00<br />
<br />
ff ff ff ff // Sequence Number<br />
01 // TxOut Count<br />
60 a0 10 2a 01 00 00 00 // Amount<br />
<br />
43 // Script Size<br />
41 04 f8 bb e9 7e d2 ac bc 5b ba 11 c6 8f 6f 1a 03 13 f9 18 f3 d3 c0 e8 47 50 55 e3 51 e3 bf 44 // Script<br />
2f 8c 8d ce e6 82 d2 45 7b dc 53 51 b7 0d d9 e3 40 26 76 6e ba 18 b0 6e ae e2 e1 02 ef d1 ab 63<br />
46 67 ac<br />
<br />
00 00 00 00 // Lock Time<br />
<br />
Coinbase Link:<br />
a9 03 ef 9d e1 91 8e 4b 44 f6 17 6a 30 c0 e7 c7 e3 43 9c 96 fb 59 73 27 47 3d 00 00 00 00 00 00 // Hash of parent block header<br />
05 // Number of links in branch<br />
05 0a c4 a1 a1 e1 bc e0 c4 8e 55 5b 1a 9f 93 52 81 96 8c 72 d6 37 9b 24 72 9c a0 42 5a 3f c3 cb // Hash #1<br />
43 3c d3 48 b3 5e a2 28 06 cf 21 c7 b1 46 48 9a ef 69 89 55 1e b5 ad 23 73 ab 61 21 06 0f 30 34 // Hash #2<br />
1d 64 87 57 c0 21 7d 43 e6 6c 57 ea ed 64 fc 18 20 ec 65 d1 57 f3 3b 74 19 65 18 3a 5e 0c 85 06 // Hash #3<br />
ac 26 02 df e2 f5 47 01 2d 1c c7 50 04 d4 8f 97 ab a4 6b d9 93 0f f2 85 c9 f2 76 f5 bd 09 f3 56 // Hash #4<br />
df 19 72 45 79 d6 5e c7 cb 62 bf 97 94 6d fc 6f b0 e3 b2 83 9b 7f da b3 7c db 60 e5 51 22 d3 5b // Hash #5<br />
00 00 00 00 // Branch sides bitmask<br />
<br />
Aux Blockchain Link:<br />
00 // Number of links in branch<br />
00 00 00 00 // Branch sides bitmask<br />
<br />
Parent Block Header:<br />
01 00 00 00 // Version<br />
08 be 13 29 5c 03 e6 7c b7 0d 00 da e8 1e a0 6e 78 b9 01 4e 5c eb 7d 9b a5 04 00 00 00 00 00 00 // Previous block hash<br />
e0 fd 42 db 8e f6 d7 83 f0 79 d1 26 be a1 2e 2d 10 c1 04 c0 92 7c d6 8f 95 4d 85 6f 9e 81 11 e5 // Merkle root<br />
9a 23 90 4e // Timestamp<br />
5d ee 09 1a // Bits<br />
1c 65 50 86 // Nonce<br />
<br />
Transactions:<br />
01 // Tx Count<br />
01 00 00 00 // Version<br />
01 // TxIn Count<br />
<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // Previous Out<br />
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff<br />
<br />
08 // Script size<br />
04 69 b2 00 1b 01 01 52 // Script<br />
ff ff ff ff // Sequence number<br />
01 // TxOut Count<br />
00 f2 05 2a 01 00 00 00 // Amount<br />
<br />
43 // Script size<br />
41 04 89 fe 91 e6 28 47 57 5c 98 de ea b0 20 f6 5f df f1 7a 3a 87 0e bb 05 82 0b 41 4f 3d 80 97 // Script<br />
21 8e c9 a6 5f 1e 0a e0 ac 35 af 72 47 bd 79 ed 1f 2a 24 67 5f ff b5 aa 6f 96 20 e1 92 0a d4 bf<br />
5a a6 ac<br />
<br />
00 00 00 00 // Lock Time<br />
</pre><br />
<br />
==Notes==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>XertroV