text:
Bitcoin-Core Developers sharing e-mail address?
I've been looking into the Github commit history of Bitcoin. I have no clue how git works, but interestingly, I'm seeing a number of developers' mail addresses associated with commits of others.
For example, Luke-Jr and Gavin Andresen's account emails have both signed commits under Wladimir's name when I run this command:
git log --all --format='%aN,%cE' | sort -u;

What gives?
... truncated:
Fordy,luke-jr+git@utopios.org
Forrest Voight,forrest@forre.st
Forrest Voight,forrest@forrest-laptop.(none)
Francesco 'makevoid' Canessa,makevoid@gmail.com
Francis GASCHET,laanwj@gmail.com
freewil,luke-jr+git@utopios.org
freewil,sean@eternalrise.com
fsb4000,fsb4000@yandex.ru
fsb4000,laanwj@gmail.com
Gaurav Rana,luke-jr+git@utopios.org
Gaurav Rana,noreply@github.com
Gavin Andresen,Administrator@.(none)
gavinandresen,gavinandresen@1a98c847-1fd6-4fd8-948a-caf3550aa51b
Gavin Andresen,gavinandresen@gmail.com
Gavin Andresen,git@bluematt.me
Gavin Andresen,laanwj@gmail.com
Gavin Andresen,luke-jr+git@utopios.org
Gavin Andresen,morcos@chaincode.com
Gavin Andresen,patrick.strateman@gmail.com
Gavin Andresen,pieter.wuille@gmail.com
Gavin Andresen,tcatm@gawab.com
Geoffrey Tsui,tsui.geoffrey@gmail.com
Giel van Schijndel,me@mortis.eu
Giuseppe Mazzotta,gdm85@users.noreply.github.com
gjs278,root@Gentoo.(none)
gladoscc,admin@glados.cc
gladoscc,elacoin@glados.cc
Glenn Willen,gwillen@nerdnet.org
globalcitizen,walter@pratyeka.org
gmaxwell,gmaxwell@gmail.com
graingert,luke-jr+git@utopios.org
graingert,tagrain@gmail.com
Greg Griffith,cryptounitedteam@gmail.com
Gregory Maxwell,falke.marco@gmail.com
Gregory Maxwell,gavinandresen@gmail.com
Gregory Maxwell,git@bluematt.me
Gregory Maxwell,gmaxwell@gmail.com
Gregory Maxwell,greg@xiph.org
Gregory Maxwell,laanwj@gmail.com
Gregory Maxwell,luke-jr+git@utopios.org
Gregory Maxwell,pieter.wuille@gmail.com
Gregory Sanders,btcdrak@gmail.com
Gregory Sanders,dev@jonasschnelli.ch
Gregory Sanders,gsanders87@gmail.com
Gregory Sanders,laanwj@gmail.com
Greg Walker,greg@learnmeabitcoin.com
grimd34th,luke-jr+git@utopios.org
grimd34th,ubpd34th@gmail.com
gubatron,gubatron@gmail.com
Guillermo Céspedes Tabárez,laanwj@gmail.com
Haakon Nilsen,haakonn@gmail.com
HaltingState,haltingstate@gmail.com
Hampus Sjöberg,hampus.sjoberg@gmail.com
Han Lin Yap,codler@gmail.com
Han Lin Yap,laanwj@gmail.com
harry,harrywu@tvunetworks.com
HarryWu,imharrywu@users.noreply.github.com
Heath,heathmatlock@gmail.com
Hector Jusforgues,contact@hectorj.net
himynameismartin,himynameismartin@gmail.com
HostFat,matt@bluematt.me
Huang Le,4tarhl@gmail.com
Huang Le,laanwj@gmail.com
Ian Carroll,him@ian.sh
Ian Kelling,ian@iankelling.org
Ian T,hello@chainquery.com
imharrywu,imharrywu@users.noreply.github.com
instagibbs,falke.marco@gmail.com
instagibbs,gsanders87@gmail.com
instagibbs,laanwj@gmail.com
instagibbs,luke-jr+git@utopios.org
instagibbs,pieter.wuille@gmail.com
Irving Ruan,irvingruan@gmail.com
Isidoro Ghezzi,isidoro.ghezzi@icloud.com
isle2983,isle2983@yahoo.com
isle2983,luke-jr+git@utopios.org
Ivan Pustogarov,ivanpustogarov@users.noreply.github.com
Ivan Pustogarov,laanwj@gmail.com
Ivo van der Sangen,laanwj@gmail.com
Ivo van der Sangen,luke-jr+git@utopios.org
Jack Grigg,jack@z.cash
Jacob Welsh,cory-nospam-@coryfields.com
Jacob Welsh,jacob@welshcomputing.com
Jacob Welsh,laanwj@gmail.com
Jakob Kramer,matt@bluematt.me
James Burkle,james.burkle@gmail.com
James Evans,falke.marco@gmail.com
James Evans,noreply@github.com
James O'Beirne,james.obeirne@gmail.com
James O'Beirne,laanwj@gmail.com
Jameson Lopp,jameson@bitgo.com
Jameson Lopp,jameson.lopp@gmail.com
Jameson Lopp,laanwj@gmail.com
Jameson Lopp,luke-jr+git@utopios.org
James White,james@jmwhite.co.uk
Janne Pulkkinen,jannepulk@gmail.com
Janne Pulkkinen,laanwj@gmail.com
Janne Pulkkinen,luke-jr+git@utopios.org
Jannes Faber,noreply@github.com
Janusz Lenar,laanwj@gmail.com
Jaromil,jaromil@dyne.org
Jarret Dyrbye,jarret.dyrbye@gmail.com
JaSK,temp@temp.temp
Jason Lewicki,laanwj@gmail.com
Jay Weisskopf,jay@jayschwa.net
Jeff Garzik,gavinandresen@gmail.com
Jeff Garzik,jeff@bloq.com
Jeff Garzik,jgarzik@bitpay.com
Jeff Garzik,jgarzik@exmulti.com
Jeff Garzik,jgarzik@peernova.com
Jeff Garzik,jgarzik@pobox.com
Jeff Garzik,jgarzik@redhat.com
Jeff Garzik,joao@bitreserve.org
Jeff Garzik,jonas.schnelli@include7.ch
Jeff Garzik,laanwj@gmail.com
Jeff Garzik,luke-jr+git@utopios.org
Jeff Garzik,pieter.wuille@gmail.com
Jeff Garzik,sipa@ulyssis.org
JeremyRand,biolizard89@gmail.com
Jeremy Rubin,cory-nospam-@coryfields.com
Jeremy Rubin,jeremy.l.rubin@gmail.com
Jeremy Rubin,luke-jr+git@utopios.org
Jeroenz0r,jeroen.marshmallow@gmail.com
Jiaxing Wang,hello.wjx@gmail.com
Jimmy Song,jaejoon@gmail.com
jl2012,jl2012@xbt.hk
JL2035,jl2035@users.noreply.github.com
jloughry,falke.marco@gmail.com
jloughry,joe.loughry@gmail.com
jmacwhyte,keatonatron@gmail.com
jnewbery,falke.marco@gmail.com
jnewbery,john@johnnewbery.com
jnewbery,laanwj@gmail.com
João Barbosa,joao@bitreserve.org
João Barbosa,joao@uphold.com
João Barbosa,laanwj@gmail.com
Joao Fonseca,falke.marco@gmail.com
Joao Fonseca,jpdf.fonseca@gmail.com
Joel Kaartinen,jkaartinen@iki.fi
Joel Kaartinen,luke-jr+git@utopios.org
JoelKatz,DavidJoelSchwartz@GMail.com
JoelKatz,pieter.wuille@gmail.com
Joerie de Gram,j.de.gram@gmail.com
Johannes Henninger,blaubaer@gmail.com
Johnathan Corgan,johnathan@corganlabs.com
Johnathan Corgan,laanwj@gmail.com
John Maguire,johnmaguire2013@gmail.com
John Newbery,greg@xiph.org
John Newbery,john@johnnewbery.com
John Newbery,laanwj@gmail.com
Johnson Lau,falke.marco@gmail.com
Johnson Lau,jl2012@users.noreply.github.com
Johnson Lau,jl2012@xbt.hk
Johnson Lau,laanwj@gmail.com
Johnson Lau,luke-jr+git@utopios.org
Johnson Lau,noreply@github.com
Johnson Lau,pieter.wuille@gmail.com
Jonas Nick,jonasd.nick@gmail.com
Jonas Nick,pieter.wuille@gmail.com
Jonas Schnelli,dev@jonasschnelli.ch
Jonas Schnelli,falke.marco@gmail.com
Jonas Schnelli,git@bluematt.me
Jonas Schnelli,greg@xiph.org
Jonas Schnelli,joao@bitreserve.org
Jonas Schnelli,jonas.schnelli@include7.ch
Jonas Schnelli,laanwj@gmail.com
Jonas Schnelli,luke-jr+git@utopios.org
Jonas Schnelli,morcos@chaincode.com
Jonas Schnelli,pieter.wuille@gmail.com
Jonas Schnelli,russ@yanofsky.org
Jonathan Brown,jbrown@bluedroplet.com
Jonathan Cross,jonathancross@users.noreply.github.com
Jon Lund Steffensen,luke-jr+git@utopios.org
jonnynewbs,john@johnnewbery.com
jonnynewbs,laanwj@gmail.com
Jordan Lewis,jordanthelewis@gmail.com
Jorge Timón,cory-nospam-@coryfields.com
Jorge Timón,face@hmel.org
Jorge Timón,falke.marco@gmail.com
Jorge Timón,jtimon@jtimon.cc
Jorge Timón,pieter.wuille@gmail.com
Josh Lehan,krellan@krellan.net
joshr,joshr@joshr.com
Josh Triplett,josh@joshtriplett.org
J Ross Nicoll,jrn@jrn.me.uk
J Ross Nicoll,luke-jr+git@utopios.org
jtimon,jtimon@blockstream.io
jtimon,jtimon@jtimon.cc
jtimon,jtimon@monetize.io
jtimon,laanwj@gmail.com
jtimon,pieter.wuille@gmail.com
Julian Haight,laanwj@gmail.com
Julian Langschaedel,meta.rb@gmail.com
Julian Yap,jyap808@users.noreply.github.com
Justin Camarena,justin121994@gmail.com
Justin Camarena,luke-jr+git@utopios.org
justmoon,pieter.wuille@gmail.com
Kalle Alm,kalle.alm@gmail.com
Kalle Alm,karljohan-alm@garage.co.jp
Kamil Domanski,kdomanski@kdemail.net
Kamil Domanski,laanwj@gmail.com
Kangmo,kangmo@nanolat.com
Karl-Johan Alm,kalle.alm@gmail.com
Karl-Johan Alm,karljohan-alm@garage.co.jp
Karl-Johan Alm,laanwj@gmail.com
kazcw,greg@xiph.org
kazcw,keziahw@gmail.com
Kaz Wesley,falke.marco@gmail.com
Kaz Wesley,keziahw@gmail.com
Kaz Wesley,luke-jr+git@utopios.org
Kefkius,kefkius@mail.com
kevin,bit.kevin@gmail.com
Kevin Cooper,k.coopr@gmail.com
Kewde,noreply@github.com
keystrike,keystrike@gmail.com
Khalahan,pieter.wuille@gmail.com
KibbledJiveElkZoo,KibbledJiveElkZoo@GMail.com
kirit93,kirit.thadaka@gmail.com
kirit93,laanwj@gmail.com
kirkalx,kirkalx@yahoo.co.nz
kiwigb,kiwigb@localhost.localdomain
kjj2,github@jerviss.org
kjj2,luke-jr+git@utopios.org
kobake,kobake@users.sourceforge.net
Koki Takahashi,k.takahashi@sonyged.com
Kosta Zertsekel,zertsekel@gmail.com
Krzysztof Jurewicz,krzysztof.jurewicz@gmail.com
kwaaak,kwaaak@gmail.com
Kyle Honeycutt,coinables@gmail.com
Lake Denman,lake@lakedenman.com
langerhans,max.keller@gmx.com
Larry Gilbert,larry@l2g.to
Lars Rasmusson,Lars.Rasmusson@sics.se
Lars Rasmusson,luke-jr+git@utopios.org
laszloh,laszloh@1a98c847-1fd6-4fd8-948a-caf3550aa51b
Lauda,falke.marco@gmail.com
Lauda,laanwj@gmail.com
Lauda,lauda.m@protonmail.ch
Lawrence Nahum,lawrence@greenaddress.it
leijurv,leijurv@gmail.com
leijurv,luke-jr+git@utopios.org
Leviathn,johnny@blockstream.io
lewuathe,lewuathe@me.com
lizhi,noreply@github.com
LongShao007,007longshao@gmail.com
lpescher,lukas_078@yahoo.ca
Luca Venturini,luca@yepa.com
Luke Dashjr,achow101-github@achow101.com
Luke Dashjr,cory-nospam-@coryfields.com
Luke Dashjr,dev@jonasschnelli.ch
Luke Dashjr,falke.marco@gmail.com
Luke Dashjr,gavinandresen@gmail.com
Luke Dashjr,greg@xiph.org
Luke Dashjr,jgarzik@redhat.com
Luke Dashjr,jtimon@jtimon.cc
Luke Dashjr,laanwj@gmail.com
Luke Dashjr,luke-jr+git@utopios.org
Luke Dashjr,pieter.wuille@gmail.com
Luke Dashjr,tcatm@gawab.com
Luke,lukem512@users.noreply.github.com
Luv Khemani,luvb@hotmail.com
m0ray,matt@bluematt.me
maiiz,laanwj@gmail.com
maiiz,zhaohaitao@huobi.com
Manuel Araoz,cory-nospam-@coryfields.com
Manuel Araoz,manuelaraoz@gmail.com
Marcel Krüger,zauguin@gmail.com
MarcoFalke,dev@jonasschnelli.ch
MarcoFalke,falke.marco@gmail.com
MarcoFalke,laanwj@gmail.com
MarcoFalke,luke-jr+git@utopios.org
Marco,falke.marco@gmail.com
MarcoFalke,morcos@chaincode.com
MarcoFalke,pieter.wuille@gmail.com
Marcos Mayorga,marcos@ncrypt.com
Marijn Stollenga,laanwj@gmail.com
Marijn Stollenga,m.stollenga@gmail.com
Mario Dian,mariodian@gmail.com
Marius Hanne,marius.hanne@sourceagency.org
Mark Friedenbach,btcdrak@gmail.com
Mark Friedenbach,jtimon@blockstream.io
Mark Friedenbach,laanwj@gmail.com
Mark Friedenbach,mark@blockstream.io
Mark Friedenbach,mark@friedenbach.org
Mark Friedenbach,mark@monetize.io
mark,mark@shotgunsoftware.com
Marko Bencun,marko.bencun@monetas.net
Marty Jones,luke-jr+git@utopios.org
Marty Jones,noreply@github.com
Masahiko Hyuga,luke-jr+git@utopios.org
Masahiko Hyuga,mail@mhyuga.jp
Mathy Vanvoorden,laanwj@gmail.com
Matt Bogosian,cory-nospam-@coryfields.com
Matt Bogosian,laanwj@gmail.com
Matt Bogosian,mtb19@columbia.edu
Matt Corallo,cory-nospam-@coryfields.com
Matt Corallo,dev@jonasschnelli.ch
Matt Corallo,falke.marco@gmail.com
Matt Corallo,gavinandresen@gmail.com
Matt Corallo,git@bluematt.me
Matt Corallo,greg@xiph.org
Matt Corallo,jgarzik@pobox.com
Matt Corallo,jgarzik@redhat.com
Matt Corallo,laanwj@gmail.com
Matt Corallo,luke-jr+git@utopios.org
Matt Corallo,matt@bluematt.me
Matt Corallo,matt@mattcorallo.com
Matt Corallo,pete@petertodd.org
Matt Corallo,pieter.wuille@gmail.com
Matt Corallo,sdaftuar@gmail.com
Matt Giuca,matt.giuca@gmail.com
Matthew Bogosian,laanwj@gmail.com
Matthew Bogosian,mtb19@columbia.edu
Matthew English,h1395010@connect.hku.hk
Matthew English,s-matthew-english@users.noreply.github.com
Matthew King,chohag@jtan.com
Matthew King,laanwj@gmail.com
Matthew Zipkin,falke.marco@gmail.com
Matthew Zipkin,Matthew.Zipkin@gmail.com
Matthew Zipkin,pinheadmz@gmail.com
Matthias Grundmann,matthias@glasmail.de
matthias,luke-jr+git@utopios.org
matthias,s.matthew.english@gmail.com
Matt,laanwj@gmail.com
Matt Quinn,matt@mattjquinn.com
Matt,sirmatt@ksu.edu
mb300sd,luke-jr+git@utopios.org
mb300sd,mb300sd@git
mb300sd,mb300sd@github
Meeh,meeh@sigterm.no
mewantsbitcoins,matt@bluematt.me
Micha,cory-nospam-@coryfields.com
Michael Bauer,michael@m-bauer.org
Michael Bemmerl,mail@mx-server.de
Michael,fanquake@gmail.com
Michael,fanquake@users.noreply.github.com
Michael Ford,cory-nospam-@coryfields.com
Michael Ford,falke.marco@gmail.com
Michael Ford,fanquake@gmail.com
Michael Ford,fanquake@users.noreply.github.com
Michael Ford,laanwj@gmail.com
Michael Ford,luke-jr+git@utopios.org
Michael Ford,noreply@github.com
Michael Goldstein,michael@bitstein.org
Michael Hendricks,luke-jr+git@utopios.org
Michael Hendricks,michael@ndrix.org
Michael Rotarius,michael-rotarius@rotamedia.de
Michagogo,michagogo@server.fake
Michagogo,Michagogo@users.noreply.github.com
Micha,laanwj@gmail.com
Michal Zima,xhire@mujmalysvet.cz
Micha,michagogo@server.fake
Micha,Michagogo@users.noreply.github.com
Midnight Magic,midnightmagic@example.com
Midnight Magic,midnightmagic@users.noreply.github.com
Mikael Wikman,mikael@swedcontent.com
Mike Cassano,mcassano@gmail.com
Mike Hearn,gavinandresen@gmail.com
Mike Hearn,hearn@google.com
Mike Hearn,laanwj@gmail.com
Mike Hearn,mike@plan99.net
Mike Hearn,pieter.wuille@gmail.com
Mikerah,mikerah14@gmail.com
Mike van Rossum,mike@mikevanrossum.nl
Misbakh-Soloviev Vadim A,laanwj@gmail.com
Mitchell Cash,luke-jr+git@utopios.org
Mitchell Cash,mitchell.cash@gmail.com
Mitchell Cash,mitchell@fastmail.com.au
Mitchell Cash,mitchell@mitchellcash.com
mrbandrews,bandrewsny@gmail.com
mrbandrews,falke.marco@gmail.com
mrbandrews,git@bluematt.me
mrbandrews,laanwj@gmail.com
mrbandrews,russ@yanofsky.org
mrbandrews,sdaftuar@gmail.com
mruddy,mruddy@users.noreply.github.com
Murch,alszacrel@web.de
Mustafa,mus@musalbas.com
Nathaniel Mahieu,nate@mahie.us
Nick Bosma,nick.bosma@gmail.com
Nick,nikzhavoronkov@gmail.com
Nicolas Benoit,laanwj@gmail.com
NicolasDorier,btcdrak@gmail.com
NicolasDorier,nicolas.dorier@gmail.com
Nicolas Dorier,noreply@github.com
NicolasDorier,pieter.wuille@gmail.com
Nicolas DORIER,pieter.wuille@gmail.com
Nils Schneider,luke-jr+git@utopios.org
Nils Schneider,nils@nilsschneider.net
Nils Schneider,nils.schneider@gmail.com
Noel Tiernan,tiernolan@gmail.com
nomnombtc,laanwj@gmail.com
nomnombtc,luke-jr+git@utopios.org
nomnombtc,mastergizmo@arcor.de
ntrgn,laanwj@gmail.com
ntrgn,ntrgnt@gmail.com
ojab,ojab@ojab.ru
olalonde,olalonde@gmail.com
Olivier Langlois,olivier@olivierlanglois.net
osmosis,shen@shen-90X3A.(none)
Otto Allmendinger,otto.allmendinger@gmail.com
ovdeathiam,krystian.maksymowicz@gmail.com
p2k,gavinandresen@gmail.com
p2k,laanwj@gmail.com
p2k,luke-jr+git@utopios.org
p2k,patrick.p2k.schneider@gmail.com
Patick Strateman,patrick.strateman@gmail.com
Patick Strateman,pieter.wuille@gmail.com
Patrick Brown,patrick.arthur.brown@gmail.com
patrick s,patrick.strateman@gmail.com
Patrick Strateman,falke.marco@gmail.com
Patrick Strateman,laanwj@gmail.com
Patrick Strateman,luke-jr+git@utopios.org
Patrick Strateman,patrick.strateman@gmail.com
Patrick Strateman,pieter.wuille@gmail.com
Patrick Varilly,dev@gim.name
Paul Georgiou,pavlos1998@gmail.com
Paul Rabahy,PRabahy@gmail.com
Pavel Janík,cory-nospam-@coryfields.com
paveljanik,falke.marco@gmail.com
Pavel Janík,falke.marco@gmail.com
paveljanik,gavinandresen@gmail.com
paveljanik,laanwj@gmail.com
Pavel Janík,laanwj@gmail.com
Pavel Janík,luke-jr+git@utopios.org
paveljanik,Pavel@Janik.cz
Pavel Janík,Pavel@Janik.cz
Pavel Vasin,cory-nospam-@coryfields.com
Pavel Vasin,laanwj@gmail.com
Pavel Vasin,luke-jr+git@utopios.org
Pavel Vasin,pavel@vasin.nl
Pavel Vasin,rat4vier@gmail.com
Pavlos Antoniou,antoniou-p@hotmail.com
Pavol Rusnak,laanwj@gmail.com
Pavol Rusnak,stick@gk2.sk
Pedro Branco,branco@uphold.com
Pedro Branco,laanwj@gmail.com
peryaudo,peraudo@gmail.com
Peter Josling,peterjosling@gmail.com
Peter Todd,dev@jonasschnelli.ch
Peter Todd,gavinandresen@gmail.com
Peter Todd,git@bluematt.me
Peter Todd,jtimon@jtimon.cc
Peter Todd,laanwj@gmail.com
Peter Todd,luke-jr+git@utopios.org
Peter Todd,patrick.strateman@gmail.com
Peter Todd,pete@petertodd.org
Peter Todd,pieter.wuille@gmail.com
Petter Reinholdtsen,laanwj@gmail.com
phantomcircuit,laanwj@gmail.com
phantomcircuit,patrick@cloudhashing.com
phantomcircuit,phantomcircuit@debian
phelixbtc,github@blockchained.com
phelixbtc,laanwj@gmail.com
Philip Kaufmann,cory-nospam-@coryfields.com
Philip Kaufmann,gavinandresen@gmail.com
Philip Kaufmann,jonas.schnelli@include7.ch
Philip Kaufmann,jonasschnelli@Jonass-MacBook-Pro.local
Philip Kaufmann,laanwj@gmail.com
Philip Kaufmann,luke-jr+git@utopios.org
Philip Kaufmann,phil.kaufmann@t-online.de
Philip Kaufmann,pieter.wuille@gmail.com
philsong,laanwj@gmail.com
Pierre Pronchery,khorben@defora.org
Pieter Wuille,btcdrak@gmail.com
Pieter Wuille,cory-nospam-@coryfields.com
Pieter Wuille,dev@jonasschnelli.ch
Pieter Wuille,dexx@bitwatch.co
Pieter Wuille,falke.marco@gmail.com
Pieter Wuille,gavinandresen@gmail.com
Pieter Wuille,git@bluematt.me
Pieter Wuille,greg@xiph.org
Pieter Wuille,james.obeirne@gmail.com
Pieter Wuille,jl2012@xbt.hk
Pieter Wuille,jonas.schnelli@include7.ch
Pieter Wuille,kdomanski@kdemail.net
Pieter Wuille,laanwj@gmail.com
Pieter Wuille,luke-jr+git@utopios.org
Pieter Wuille,matt@bluematt.me
Pieter Wuille,pete@petertodd.org
Pieter Wuille,phil.kaufmann@t-online.de
Pieter Wuille,pieterw@google.com
Pieter Wuille,pieter.wuille@gmail.com
Pieter Wuille,sdaftuar@gmail.com
Pieter Wuille,sipa@ulyssis.org
Pieter Wuille,temp@temp.temp
poole_party,james@esixteen.co
practicalswift,laanwj@gmail.com
practicalswift,practicalswift@users.noreply.github.com
Prayag Verma,laanwj@gmail.com
Prayag Verma,prayag.verma@gmail.com
pryds,laanwj@gmail.com
pstratem,patrick.strateman@gmail.com
ptschip,falke.marco@gmail.com
ptschip,laanwj@gmail.com
ptschip,peter.tschipper@gmail.com
Puru,tuladharpuru@gmail.com
randy-waterhouse,kiwigb@localhost.localdomain
randy-waterhouse,kiwigb@yahoo.com
randy-waterhouse,laanwj@gmail.com
randy-waterhouse,luke-jr+git@utopios.org
randy-waterhouse,noone@yodasan
Rav3nPL,rav3n.pl@gmail.com
R E Broadley,falke.marco@gmail.com
R E Broadley,laanwj@gmail.com
R E Broadley,luke-jr+git@utopios.org
R E Broadley,pieter.wuille@gmail.com
R E Broadley,rebroad+github@gmail.com
redshark1802,redshark@gmx.org
regergregregerrge,regergregregerrge@oxymail.de
Ricardo M. Correia,luke-jr+git@utopios.org
Ricardo M. Correia,rcorreia@wizy.org
Richard Kiss,him@richardkiss.com
Richard Schwab,mail@richardschwab.de
Richard Schwab,mail@w.tf-w.tf
richierichrawr,richierichrawr@users.noreply.github.com
rion,laanwj@gmail.com
rion,rion@cs.stanford.edu
Robert Backhaus,laanwj@gmail.com
Robert Backhaus,robbak@robbak.com
Robert McLaughlin,robert@sparkk.us
Rob Van Mieghem,gavinandresen@gmail.com
Rob Van Mieghem,laanwj@gmail.com
rodasmith,falke.marco@gmail.com
rodasmith,noreply@github.com
ロハン ダル,rohun-dhar@MN14042102.local
Roman Mindalev,laanwj@gmail.com
Roman Mindalev,r000n@r000n.net
Rose Toomey,laanwj@gmail.com
Rose Toomey,rktoomey@gmail.com
Ross Nicoll,jrn@jrn.me.uk
Ross Nicoll,luke-jr+git@utopios.org
Roy Badami,roy@gnomon.org.uk
Ruben Dario Ponticeli,laanwj@gmail.com
Ruben Dario Ponticelli,laanwj@gmail.com
Ruben Dario Ponticelli,rdponticelli@gmail.com
Rubén Darío Ponticelli,rdponticelli@gmail.com
Ruben de Vries,laanwj@gmail.com
Ruben de Vries,ruben@rubensayshi.com
Rune K. Svendsen,laanwj@gmail.com
Rune K. Svendsen,luke-jr+git@utopios.org
Rune K Svendsen,runesvend@gmail.com
Rune K. Svendsen,runesvend@gmail.com
Russell Yanofsky,falke.marco@gmail.com
Russell Yanofsky,laanwj@gmail.com
Russell Yanofsky,luke-jr+git@utopios.org
Russell Yanofsky,nicolas.dorier@gmail.com
Russell Yanofsky,russ@yanofsky.org
Russell Yanofsky,sdaftuar@gmail.com
Rusty Russell,rusty@rustcorp.com.au
rxl,me@ryanshea.org
Ryan Havar,falke.marco@gmail.com
Ryan Havar,laanwj@gmail.com
Ryan Havar,noreply@github.com
Ryan Havar,rhavar@protonmail.com
Ryan Niebur,ryanryan52@gmail.com
Ryan X. Charles,ryanxcharles@gmail.com
Saivann,laanwj@gmail.com
Saivann,saivann@gmail.com
sandakersmann,cory-nospam-@coryfields.com
sandakersmann,laanwj@gmail.com
sandakersmann,sandakersmann@users.noreply.github.com
sandos,sandos@sanddesk.(none)
Sanjay Ghemawat,gavinandresen@gmail.com
Santiago M. Mola,coldwind@coldwind.org
Satoshi Nakamoto,gavinandresen@gmail.com
Scott Ellis,sje397@gmail.com
Scott Howard,showard314@gmail.com
Scott Willeke,scott@willeke.com
Sergey Kazenyuk,kazenyuk@gmail.com
SergioDemianLerner,laanwj@gmail.com
Sev,git@sevastos.com
Sev,luke-jr+git@utopios.org
Shane Wegner,shane-github@csy.ca
shaolinfry,jtimon@jtimon.cc
Shaul Kfir,shaul.kfir@gmail.com
Shawn Wilkinson,laanwj@gmail.com
Shawn Wilkinson,me@super3.org
Shigeya Suzuki,laanwj@gmail.com
Shigeya Suzuki,shigeya@wide.ad.jp
shshshsh,laanwj@gmail.com
shshshsh,shshshsh@sdsdsdfsd.invalid
Simon de la Rouviere,simon@delarouviere.com
Simone Madeo,noreply@github.com
Simon Males,sime@sime.net.au
Sined,nightsbird@gmail.com
sinetek,laanwj@gmail.com
sinetek,pitwuu@gmail.com
sinetek,root@lstar.my.domain
sirius-m,sirius-m@1a98c847-1fd6-4fd8-948a-caf3550aa51b
sje397,sje397@gmail.com
sje,laanwj@gmail.com
S. Matthew English,laanwj@gmail.com
S. Matthew English,luke-jr+git@utopios.org
S. Matthew English,noreply@github.com
s_nakamoto,s_nakamoto@1a98c847-1fd6-4fd8-948a-caf3550aa51b
Spencer Lievens,noreply@github.com
spin,spin@ctwug.za.net
Stanislas Marion,john@johnnewbery.com
Stéphane Gimenez,dev@gim.name
Stephane Glondu,luke-jr+git@utopios.org
Stephane Glondu,steph@glondu.net
Stephen,scmorse@colby.edu
Steven,luke-jr+git@utopios.org
Steven,noreply@github.com
Stuart Cardall,developer@it-offshore.co.uk
Stuart Cardall,laanwj@gmail.com
Subo1978,shuebbel@gmx.de
Suhas Daftuar,btcdrak@gmail.com
Suhas Daftuar,dev@jonasschnelli.ch
Suhas Daftuar,falke.marco@gmail.com
Suhas Daftuar,git@bluematt.me
Suhas Daftuar,greg@xiph.org
Suhas Daftuar,jl2012@xbt.hk
Suhas Daftuar,laanwj@gmail.com
Suhas Daftuar,luke-jr+git@utopios.org
Suhas Daftuar,morcos@chaincode.com
Suhas Daftuar,pete@petertodd.org
Suhas Daftuar,pieter.wuille@gmail.com
Suhas Daftuar,sdaftuar@chaincode.com
Suhas Daftuar,sdaftuar@gmail.com
super3,me@super3.org
Suriyaa Kudo,luke-jr+git@utopios.org
Suriyaa Kudo,SuriyaaKudoIsc@users.noreply.github.com
Sven Slootweg,pieter.wuille@gmail.com
svost,ya.nowa@yandex.ru
tailsjoin,laanwj@gmail.com
Takashi Mitsuta,knhn1117@gmail.com
Tamas Blummer,tamas@bitsofproof.com
Tariq Bashir,laanwj@gmail.com
Tawanda Kembo,tawanda@zimstay.com
tcatm,jgarzik@pobox.com
tcatm,tcatm@gawab.com
฿tcDrak,btcdrak@users.noreply.github.com
฿tcDrak,laanwj@gmail.com
Telepatheic,thomas@instantsolve.net
Teran McKinney,laanwj@gmail.com
TheLazieR Yip,laanwj@gmail.com
TheLazieR Yip,noreply@github.com
theuni,gavinandresen@gmail.com
theuni,laanwj@gmail.com
theuni,theuni-nospam@xbmc.org
Thomas Holenstein,laanwj@gmail.com
Thomas Holenstein,thomas.holenstein@gmail.com
Thomas Kerin,afk11@users.noreply.github.com
Thomas Kerin,btcdrak@gmail.com
Thomas Kerin,pieter.wuille@gmail.com
Thomas Snider,tjps636@gmail.com
Thomas Zander,laanwj@gmail.com
Thomas Zander,thomas@thomaszander.se
Timon Rapp,timon@zaeda.net
Timothy Redaelli,luke-jr+git@utopios.org
Timothy Redaelli,timothy.redaelli@gmail.com
Timothy Stranex,laanwj@gmail.com
Timothy Stranex,timothy@Timothys-MacBook-Pro.local
tm314159,laanwj@gmail.com
tm314159,tm314159@users.noreply.github.com
Tom Geller,tom@tomgeller.com
Tom Harding,laanwj@gmail.com
Tom Harding,tomh@thinlink.com
Torstein Husebø,laanwj@gmail.com
Torstein Husebø,torstein@huseboe.net
Trevin Hofmann,laanwj@gmail.com
Trevin Hofmann,trevinhofmann@gmail.com
tucenaber,pieter.wuille@gmail.com
tulip,tulip@JBinUp.local
Tyler Hardin,th020394@gmail.com
UdjinM6,cory-nospam-@coryfields.com
UdjinM6,luke-jr+git@utopios.org
UdjinM6,UdjinM6@dash.org
unsystemizer,laanwj@gmail.com
unsystemizer,noreply@github.com
unsystemizer,something@gmail.com
Vaclav Vobornik,git@vobornik.eu
Vegard Nossum,gavinandresen@gmail.com
Vegard Nossum,luke-jr+git@utopios.org
Venkatesh Srinivas,jgarzik@pobox.com
Venkatesh Srinivas,me@endeavour.zapto.org
Veres Lajos,luke-jr+git@utopios.org
Veres Lajos,vlajos@gmail.com
vhf / victor felder,victorfelder@gmail.com
Victor Leschuk,luke-jr+git@utopios.org
Victor Leschuk,vleschuk@gmail.com
Vinnie Falco,vinnie.falco@gmail.com
Virgil Dupras,hsoft@hardcoded.net
Vitalii Demianets,cory-nospam-@coryfields.com
Warren Togami,cory-nospam-@coryfields.com
Warren Togami,gavinandresen@gmail.com
Warren Togami,laanwj@gmail.com
Warren Togami,wtogami@gmail.com
Whit J,laanwj@gmail.com
Whit J,whitj00@users.noreply.github.com
whythat,falke.marco@gmail.com
whythat,luke-jr+git@utopios.org
whythat,yuri.zhykin@gmail.com
Wil Bown,wilbown@users.noreply.github.com
Will Binns,binns@21.co
Will Binns,will@trek.io
William Yager,will.yager@gmail.com
Witchspace,witchspace81@gmail.com
Wladimir J. van der Laan,cory-nospam-@coryfields.com
Wladimir J. van der Laan,cozzlovan@yahoo.com
Wladimir J. van der Laan,dev@jonasschnelli.ch
Wladimir J. van der Laan,falke.marco@gmail.com
Wladimir J. van der Laan,gavinandresen@gmail.com
Wladimir J. van der Laan,greg@xiph.org
Wladimir J. van der Laan,jonas.schnelli@include7.ch
Wladimir J. van der Laan,jtimon@blockstream.io
Wladimir J. van der Laan,jtimon@jtimon.cc
Wladimir J. van der Laan,laanwj@gmail.com
Wladimir J. van der Laan,luke-jr+git@utopios.org
Wladimir J. van der Laan,morcos@chaincode.com
Wladimir J. van der Laan,pete@petertodd.org
Wladimir J. van der Laan,phil.kaufmann@t-online.de
Wladimir J. van der Laan,pieter.wuille@gmail.com
Wladimir J. van der Laan,temp@temp.temp
Wladimir J. van der Laan,witchspace81@gmail.com
Wladimir van der Laan,laanwj@gmail.com
wodry,falke.marco@gmail.com
wodry,laanwj@gmail.com
wodry,wodry@users.noreply.github.com
xanatos,laanwj@gmail.com
xanatos,luke-jr+git@utopios.org
xanatos,xanatos@geocities.com
xHire,matt@bluematt.me
xor-freenet,xor@freenetproject.org
Yoichi Hirai,i@yoichihirai.com
Yuri Zhykin,yuri.zhykin@gmail.com
Zak Wilcox,iwilcox@iwilcox.me.uk
Zak Wilcox,laanwj@gmail.com
Zak Wilcox,luke-jr+git@utopios.org

Can you please specify/clarify what is the question? This seems more like a post than a question

Yea. Why are the bitcoin developers signing with cross-linked names and addresses?

Fyi, I ran this command to get the e-mails, within the bitcoin github directory:  git log --all --format='%aN,%cE' | sort -u;

Correct, the command fetches the e-mails. I don't really about the regex in command, but I manually examined the git log where I am not able to spot these pairs.

I think something different happens when you squash the commits from multiple authors. I encourage you to manually examine the logs to convince yourself

@G.Maxwell Have you ever considered that all the fake news against Bitcoin may have been manufactured by Ethereum? https://ethereum.stackexchange.com/questions/46700/what-are-the-impacts-of-the-ethereum-pre-sale-pyramidal-wealth-distribution-an

What you are seeing has nothing to do with git history manipulation nor with blockstream. It is related to your choice of format specifier. You chose to use %aN,%cE which means author name, committer email. However, in git, the author and the committer are not necessarily the same person. The author is the person who wrote the patch and the committer is the person who actually adds the patch to the repo. This happens in Core with backports. Someone (the author) writes the patch which gets merged into the master branch of the repo. Later someone else (the committer) uses git cherry-pick to pick the specific commits that made those changes and backport them to a previous version to be later released as a new minor version. The nature of git cherry-pick is that the author of the patch is preserved, but the committer becomes the person who performed the cherry-pick. This is what is causing the discrepancy in your list.
An accurate list of authors and emails would be done using
git log --all --format='%aN,%aE' | sort -u

Running that command gives me the following output:
฿tcDrak,btcdrak@users.noreply.github.com
21E14,21xe14@gmail.com
Abraham Jewowich,abuse@loljews.com
accraze,accraze@gmail.com
Adam Brown,adam@deftnerd.com
Adam Weiss,adam@signal11.com
Addy Yeow,ayeowch@gmail.com
adlawren,adlawren010@gmail.com
Ahmad Kazi,plaxton@users.noreply.github.com
aideca,aideca@users.noreply.github.com
Aitor Pazos,mail@aitorpazos.es
Alex B,paraipanakos@gmail.com
Alex Morcos,morcos@chaincode.com
Alex van der Peet,alex.van.der.peet@gmail.com
Alex Waters,AmpedAl@Gmail.com
Alex,alex
Alexander Jeng,alexanderjeng@gmail.com
Alexander Kjeldaas,alexander.kjeldaas@gmail.com
Alexander Regueiro,alexreg@me.com
Alexey Vesnin,serxis@gmail.com
Alfie John,alfie@alfie.wtf
Alice Wonder,github@domblogger.net
Alistair Buxton,a.j.buxton@gmail.com
Allan Doensen,allan@doensen.com
Alon Muroch,alonmuroch@gmail.com
AlSzacrel,alszacrel@web.de
Altoidnerd,allenmajs1@gmail.com
Altoidnerd,altoidnerd.btc@gmail.com
Amir Abrams,AmirAbrams@users.noreply.github.com
Amir Yalon,git@please.nospammail.net
Anders Øyvind Urke-Sætre,andersoyvind@gmail.com
Anditto Heristyo,anditto.heristyo@gmail.com
Andrea D'Amore,anddam@brapi.net
Andreas Schildbach,andreas@schildbach.de
Andrés G. Aragoneses,knocte@gmail.com
Andrew C,achow101@gmail.com
Andrew Chow,achow101@gmail.com
Andrew Chow,achow101-github@achow101.com
Andrew Poelstra,apoelstra@wpsoftware.net
Andrew Poelstra,asp11@sfu.ca
Andrew,achow101@gmail.com
Andrey Alekseenko,al42and@gmail.com
Andrey,al42and@gmail.com
Andriy Voskoboinyk,andriivos@gmail.com
anduck,anduck@users.noreply.github.com
Andy Alness,andy@coinbase.com
Ang Iong Chun,angiongchun@gmail.com
Anonymous,none@anon
Anthony Towns,aj@erisian.com.au
antonio-fr,anferron@gmail.com
APerson241,setup.pyc@gmail.com
ariel,ariel@ficticio.com
Arnav Singh,arnavion@gmail.com
Arne Brutschy,abrutschy@xylon.de
Ashley Holman,dscvlt@gmail.com
--author=Satoshi Nakamoto,satoshin@gmx.com
Awemany,awemany@protonmail.com
ayeowch,ayeowch@gmail.com
azeteki,azeteki@safe-mail.net
b6393ce9-d324-4fe1-996b-acf82dbc3d53,m8r-emkdvd@mailinator.com
Bardi Harborow,bardi_harborow@yahoo.com.au
Ben Holden-Crowther,benhc@live.co.uk
Ben Holden-Crowther,benhc123@users.noreply.github.com
Benedict Chan,bencxr@fragnetics.com
bikinibabe,amberwelch@unomaha.edu
BitcoinPRReadingGroup,gsanders.87@gmail.com
bitsofproof,tamas@bitsofproof.com
Blake Jakopovic,blake.jakopovic@gmail.com
Blitzboom,anon@none
Bob McElrath,bob@mcelrath.org
Bob McElrath,bob_git@mcelrath.org
Brandon Dahler,brandon.dahler@gmail.com
Braydon Fuller,braydon@bitpay.com
Brian Deery,brian@factom.org
Bryan Bishop,kanzure@gmail.com
BtcDrak,btcdrak@gmail.com
burger2,birger.hedman@gmail.com
calebogden,email@calebogden.com
Calvin Owens,jcalvinowens@gmail.com
Calvin Tam,calvinyhtam@gmail.com
cardpuncher,mauron@vmail.me
Carlo Alberto Ferraris,github@cafxx.strayorange.com
Carlos Pizarro,kr105@kr105.com
Casey Rodarmor,casey@rodarmor.com
Cédric Félizard,cedric@felizard.fr
Celil,celil.kj@gmail.com
celil-kj,celil.kj@gmail.com
centaur1,centaur1@users.noreply.github.com
charlescharles,platypode@gmail.com
Chirag Davé,c@chirag.io
Chris Arnesen,chris.arnesen@gmail.com
Chris Beams,chris@beams.io
Chris Gavin,chris@chrisgavin.me
Chris Howie,me@chrishowie.com
Chris Kleeschulte,chrisk@bitpay.com
Chris Moore,dooglus@gmail.com
Chris Stewart,stewart.chris1234@gmail.com
Chris Wheeler,chris@haydenwheeler.com
Chris,chris@vikki-old.(none)
Christian Barcenas,christian@cbarcenas.com
Christian Decker,cdecker@tik.ee.ethz.ch
Christian Decker,decker.christian@gmail.com
Christian von Roques,roques@mti.ag
Christopher Latham,sudosurootdev@gmail.com
Chuck LeDuc Díaz,chuck.leduc@sage.com
Chuck,chuck@borboggle.com
Ciemon,ciemon@gmail.com
cjdelisle,calebdelisle@lavabit.com
Clark Gaebel,cgaebel@csclub.uwaterloo.ca
Clinton Christian,Clinton.Christian@me.com
coblee,chocobo@alum.mit.edu
coderrr,coderrr.contact@gmail.com
CohibAA,CohibAA@users.noreply.github.com
Colin Dean,git@cad.cx
constantined,nobody@constantined.com
Corinne Dashjr,corinne+git@dashjr.org
Cory Fields,cory-nospam-@coryfields.com
Cory Fields,theuni-nospam-@xbmc.org
Cozz Lovan,cozzlovan@yahoo.com
crowning-,crowning-@users.noreply.github.com
CryptAxe,cryptaxe@gmail.com
CryptoVote,cryptovote@yandex.com
dabaopku,guocong89@gmail.com
Dagur Valberg Johannsson,dagurval@pvv.ntnu.no
Daira Hopwood,daira@jacaranda.org
Dan Helfman,witten@torsion.org
Dan Loewenherz,dloewenherz@gmail.com
Daniel Aleksandersen,code@daniel.priv.no
Daniel Cousens,dcousens@users.noreply.github.com
Daniel Cousens,github@dcousens.com
Daniel Folkinshteyn,nanotube@users.sourceforge.net
Daniel Holbert,dholbert@cs.stanford.edu
Daniel Kraft,d@domob.eu
Daniel Larimer,dlarimer@gmail.com
Daniel Newton,djpnewton@gmail.com
daniel,arowser@gmail.com
Danube,anon@none
Dave Collins,davec@conformal.com
David A. Harding,dave@dtrt.org
David FRANCOIS,david.francois@webflows.fr
David Griffith,dave@661.org
David Grogan,dgrogan@chromium.org
David Hill,dhill@conformal.com
David Hill,dhill@mindcry.org
David Joel Schwartz,davidjoelschwartz@gmail.com
David Perry,enmaku@gmail.com
David Serrano,dserrano5@dserrano5.es
Dawid Spiechowicz,spiechu@gmail.com
Dean Lee,xslidian@gmail.com
default,default@default-dell.(none)
Denis Lukianov,denis@voxelsoft.com
Derek Miller,Derek701@users.noreply.github.com
Derek701,brainish@gmail.com
Dev Random,c1.github@niftybox.net
devrandom,c1.github@niftybox.net
dexX7,dexx@bitwatch.co
dexX7,ugithub@bitwatch.co
Diego Viola,diego.viola@gmail.com
ditto-b,ditto-b@users.noreply.github.com
ditto-b,nipun.d93+evil@gmail.com
djpnewton,djpnewton@gmail.com
dllud,david.ludovino@gmail.com
Dmitry Smirnov,onlyjob@member.fsf.org
Dominyk Tiller,DomT4@users.noreply.github.com
Don Patterson,d_j_p_3@djp3.net
Doug Huff,mith@jrbobdobbs.org
Doug,doug@bitcoinarmory.com
Doug,joroark@vt.edu
Douglas Huff,mith@jrbobdobbs.org
Douglas Roark,doug@bloq.com
Drak,drak@zikula.org
duanemoody,duane_moody@yahoo.com
Dwayne C. Litzenberger,dlitz@dlitz.net
Dylan Noblesmith,nobled@dreamwidth.org
Earlz,earlz@earlz.net
Elias Rohrer,rohrer@informatik.hu-berlin.de
elichai,elichai.turkel@gmail.com
elkingtowa,elkingtowa@gmail.com
Elliot Olds,elliotolds@gmail.com
ENikS,evgeni@eniks.com
Eric Hosmer,EricJ2190@gmail.com
Eric Lombrozo,elombrozo@gmail.com
Eric R. Schulz,ersmail@gmail.com
Eric S. Bullington,eric.s.bullington@gmail.com
Eric Shaw Jr,ericshaw.linux@gmail.com
Eric Shaw,ericshaw.linux@gmail.com
Eric Shaw,ericshawlinux@users.noreply.github.com
Eric Swanson,eswanson@alloscomp.com
Erik Mossberg,lingonvecka@gmail.com
error10,error@ioerror.us
Esteban Ordano,eordano@gmail.com
Ethan Heilman,Ethan.R.Heilman@gmail.com
EthanHeilman,ethan.r.heilman@gmail.com
Everett Forth,everett.forth@gmail.com
Fabian H jr.,fabianherediajr@yahoo.com.mx
Fabian Raetz,fabian.raetz@gmail.com
face,face@hmel.org
fanquake,fanquake@gmail.com
fcicq,fcicq@fcicq.net
Federico Bond,federicobond@gmail.com
Federico Faggiano,federico.sk@katamail.com
flack,flack@contentcontrol-berlin.de
Flavien Charlon,flavien@charlon.net
Florian Schmaus,flo@geekplace.eu
Florin,florin@libertv.ro
flower,flower@k1024.de
Fordy,fanquake@gmail.com
Forrest Voight,forrest@forre.st
Forrest Voight,forrest@forrest-laptop.(none)
Francesco 'makevoid' Canessa,makevoid@gmail.com
Francis GASCHET,fg@numlog.fr
freewil,sean@eternalrise.com
fsb4000,fsb4000@yandex.ru
Gaurav Rana,bitcoinsSG@gmail.com
Gavin Andresen,gavinandresen@gmail.com
gavinandresen,gavinandresen@1a98c847-1fd6-4fd8-948a-caf3550aa51b
Geoffrey Tsui,tsui.geoffrey@gmail.com
Giel van Schijndel,me@mortis.eu
Giuseppe Mazzotta,gdm85@users.noreply.github.com
gjs278,admin@garyshood.com
gladoscc,admin@glados.cc
gladoscc,elacoin@glados.cc
Glenn Willen,gwillen@nerdnet.org
globalcitizen,walter@pratyeka.org
gmaxwell,gmaxwell@gmail.com
graingert,tagrain@gmail.com
Greg Griffith,cryptounitedteam@gmail.com
Greg Walker,greg@learnmeabitcoin.com
Gregory Maxwell,gmaxwell@gmail.com
Gregory Maxwell,greg@xiph.org
Gregory Sanders,gsanders87@gmail.com
grimd34th,ubpd34th@gmail.com
gubatron,gubatron@gmail.com
Guillermo Céspedes Tabárez,dev.dertin@gmail.com
Haakon Nilsen,haakonn@gmail.com
HaltingState,haltingstate@gmail.com
Hampus Sjöberg,hampus.sjoberg@gmail.com
Han Lin Yap,codler@gmail.com
harry,harrywu@tvunetworks.com
HarryWu,imharrywu@users.noreply.github.com
Heath,heathmatlock@gmail.com
Hector Jusforgues,contact@hectorj.net
himynameismartin,himynameismartin@gmail.com
HostFat,hostfat@gmail.com
Huang Le,4tarhl@gmail.com
Ian Carroll,him@ian.sh
Ian Kelling,ian@iankelling.org
Ian T,hello@chainquery.com
imharrywu,imharrywu@users.noreply.github.com
instagibbs,gsanders87@gmail.com
Irving Ruan,irvingruan@gmail.com
Isidoro Ghezzi,isidoro.ghezzi@icloud.com
isle2983,isle2983@yahoo.com
Ivan Pustogarov,ivanpustogarov@users.noreply.github.com
Ivo van der Sangen,ivdsangen@gmail.com
J Ross Nicoll,jrn@jrn.me.uk
Jack Grigg,jack@z.cash
Jacob Welsh,jacob@welshcomputing.com
Jakob Kramer,jakob.kramer@gmx.de
James Burkle,james.burkle@gmail.com
James Evans,keystrike@users.noreply.github.com
James O'Beirne,james.obeirne@gmail.com
James White,jamesmacwhite@users.noreply.github.com
Jameson Lopp,jameson.lopp@gmail.com
Jameson Lopp,jameson@bitgo.com
Janne Pulkkinen,jannepulk@gmail.com
Jannes Faber,jannes.faber@gmail.com
Janusz Lenar,malleor@users.noreply.github.com
Jaromil,jaromil@dyne.org
Jarret Dyrbye,jarret.dyrbye@gmail.com
JaSK,temp@temp.temp
Jason Lewicki,lewicki.jason@gmail.com
Jay Weisskopf,jay@jayschwa.net
Jeff Garzik,jeff@bloq.com
Jeff Garzik,jeff@garzik.org
Jeff Garzik,jgarzik@bitpay.com
Jeff Garzik,jgarzik@exmulti.com
Jeff Garzik,jgarzik@pobox.com
Jeremy Rubin,jeremy.l.rubin@gmail.com
JeremyRand,biolizard89@gmail.com
Jeroenz0r,jeroen.marshmallow@gmail.com
Jiaxing Wang,hello.wjx@gmail.com
Jimmy Song,jaejoon@gmail.com
jl2012,jl2012@xbt.hk
JL2035,jl2035@users.noreply.github.com
jloughry,joe.loughry@gmail.com
jmacwhyte,keatonatron@gmail.com
jnewbery,john@johnnewbery.com
João Barbosa,joao@bitreserve.org
João Barbosa,joao@uphold.com
Joao Fonseca,jpdf.fonseca@gmail.com
Joel Kaartinen,jkaartinen@iki.fi
JoelKatz,DavidJoelSchwartz@GMail.com
Joerie de Gram,j.de.gram@gmail.com
Johannes Henninger,blaubaer@gmail.com
John Maguire,johnmaguire2013@gmail.com
John Newbery,john@johnnewbery.com
Johnathan Corgan,johnathan@corganlabs.com
Johnson Lau,jl2012@users.noreply.github.com
Johnson Lau,jl2012@xbt.hk
Jon Lund Steffensen,jonlst@gmail.com
Jonas Nick,jonasd.nick@gmail.com
Jonas Schnelli,dev@jonasschnelli.ch
Jonas Schnelli,jonas.schnelli@include7.ch
Jonas Schnelli,jonasschnelli@Jonass-MacBook-Pro.local
Jonathan Brown,jbrown@bluedroplet.com
Jonathan Cross,jonathancross@users.noreply.github.com
jonnynewbs,jonnynewbs@gmail.com
Jordan Lewis,jordanthelewis@gmail.com
Jorge Timón,jtimon@jtimon.cc
Josh Lehan,krellan@krellan.net
Josh Triplett,josh@joshtriplett.org
joshr,joshr@joshr.com
jtimon,jtimon@blockstream.io
jtimon,jtimon@jtimon.cc
jtimon,jtimon@monetize.io
Julian Haight,github@a.julianhaight.com
Julian Langschaedel,meta.rb@gmail.com
Julian Yap,jyap808@users.noreply.github.com
Justin Camarena,justin121994@gmail.com
justmoon,justmoon@members.fsf.org
Kalle Alm,kalle.alm@gmail.com
Kamil Domanski,kdomanski@kdemail.net
Kangmo,kangmo@nanolat.com
Karl-Johan Alm,kalle.alm@gmail.com
Karl-Johan Alm,karljohan-alm@garage.co.jp
Kaz Wesley,keziahw@gmail.com
kazcw,keziahw@gmail.com
Kefkius,kefkius@mail.com
Kevin Cooper,k.coopr@gmail.com
kevin,bit.kevin@gmail.com
Kewde,code@shadowproject.io
keystrike,keystrike@users.noreply.github.com
Khalahan,khal@bitcoin-contact.org
KibbledJiveElkZoo,KibbledJiveElkZoo@GMail.com
kirit93,kirit.thadaka@gmail.com
kirkalx,kirkalx@yahoo.co.nz
kiwigb,kiwigb@localhost.localdomain
kjj2,github@jerviss.org
kobake,kobake@users.sourceforge.net
Koki Takahashi,Koki.Takahashi@jp.sony.com
Kosta Zertsekel,zertsekel@gmail.com
Krzysztof Jurewicz,krzysztof.jurewicz@gmail.com
kwaaak,kwaaak@gmail.com
Kyle Honeycutt,coinables@gmail.com
Lake Denman,lake@lakedenman.com
langerhans,max.keller@gmx.com
Larry Gilbert,larry@l2g.to
Lars Rasmusson,Lars.Rasmusson@sics.se
laszloh,laszloh@1a98c847-1fd6-4fd8-948a-caf3550aa51b
Lauda,lauda.m@protonmail.ch
Lawrence Nahum,lawrence@greenaddress.it
leijurv,leijurv@gmail.com
Leviathn,johnny@blockstream.io
lewuathe,lewuathe@me.com
lizhi,cqtenq9@gmail.com
LongShao007,007longshao@gmail.com
lpescher,lukas_078@yahoo.ca
Luca Venturini,luca@yepa.com
Luke Dashjr,luke-jr+git@utopios.org
Luke,lukem512@users.noreply.github.com
Luv Khemani,luvb@hotmail.com
m0ray,anon@none
maiiz,maiiz@users.noreply.github.com
Manuel Araoz,manuelaraoz@gmail.com
Marcel Krüger,zauguin@gmail.com
Marco,falke.marco@gmail.com
MarcoFalke,falke.marco@gmail.com
Marcos Mayorga,mm@mm-studios.com
Marijn Stollenga,m.stollenga@gmail.com
Mario Dian,mariodian@gmail.com
Marius Hanne,marius.hanne@sourceagency.org
Mark Friedenbach,mark@blockstream.io
Mark Friedenbach,mark@friedenbach.org
Mark Friedenbach,mark@monetize.io
mark,mark@shotgunsoftware.com
Marko Bencun,marko.bencun@monetas.net
Marty Jones,murtin.jones@gmail.com
Masahiko Hyuga,mail@mhyuga.jp
Mathy Vanvoorden,mathy@vanvoorden.be
Matt Bogosian,mtb19@columbia.edu
Matt Corallo,git@bluematt.me
Matt Corallo,matt@bluematt.me
Matt Corallo,matt@mattcorallo.com
Matt Giuca,matt.giuca@gmail.com
Matt Quinn,matt@mattjquinn.com
Matt,sirmatt@ksu.edu
Matthew Bogosian,mtb19@columbia.edu
Matthew English,s-matthew-english@users.noreply.github.com
Matthew King,chohag@jtan.com
Matthew Zipkin,pinheadmz@gmail.com
Matthias Grundmann,matthias@glasmail.de
matthias,s.matthew.english@gmail.com
mb300sd,mb300sd@git
mb300sd,mb300sd@github
Meeh,meeh@sigterm.no
mewantsbitcoins,anon@none
Micha,michagogo@server.fake
Micha,Michagogo@users.noreply.github.com
Michael Bauer,michael@m-bauer.org
Michael Bemmerl,mail@mx-server.de
Michael Ford,fanquake@gmail.com
Michael Ford,fanquake@users.noreply.github.com
Michael Goldstein,michael@bitstein.org
Michael Hendricks,michael@ndrix.org
Michael Rotarius,michael-rotarius@rotamedia.de
Michael,fanquake@gmail.com
Michael,fanquake@users.noreply.github.com
Michagogo,michagogo@server.fake
Michagogo,Michagogo@users.noreply.github.com
Michal Zima,xhire@mujmalysvet.cz
Midnight Magic,midnightmagic@example.com
Midnight Magic,midnightmagic@users.noreply.github.com
Mikael Wikman,mikael@swedcontent.com
Mike Cassano,mcassano@gmail.com
Mike Hearn,hearn@google.com
Mike Hearn,mike@plan99.net
Mike Hearn,mike@riker.plan99.net
Mike van Rossum,mike@mikevanrossum.nl
Mikerah,mikerah14@gmail.com
Misbakh-Soloviev Vadim A,mva@mva.name
Mitchell Cash,mitchell.cash@gmail.com
Mitchell Cash,mitchell@fastmail.com.au
Mitchell Cash,mitchell@mitchellcash.com
mrbandrews,bandrewsny@gmail.com
mruddy,mruddy@users.noreply.github.com
Murch,alszacrel@web.de
Mustafa,mus@musalbas.com
Nathaniel Mahieu,nate@mahie.us
Nick Bosma,nick.bosma@gmail.com
Nick,nikzhavoronkov@gmail.com
Nicolas Benoit,nbenoit@tuxfamily.org
Nicolas Dorier,nicolas.dorier@gmail.com
Nicolas DORIER,nicolas.dorier@gmail.com
NicolasDorier,nicolas.dorier@gmail.com
Nils Schneider,nils.schneider@gmail.com
Nils Schneider,nils@nilsschneider.net
Noel Tiernan,tiernolan@gmail.com
nomnombtc,mastergizmo@arcor.de
ntrgn,ntrgnt@gmail.com
ojab,ojab@ojab.ru
olalonde,olalonde@gmail.com
Olivier Langlois,olivier@olivierlanglois.net
osmosis,stevenwagner@gmail.com
Otto Allmendinger,otto.allmendinger@gmail.com
ovdeathiam,krystian.maksymowicz@gmail.com
p2k,patrick.p2k.schneider@gmail.com
Patick Strateman,patrick.strateman@gmail.com
Patrick Brown,patrick.arthur.brown@gmail.com
patrick s,patrick.strateman@gmail.com
Patrick Strateman,patrick.strateman@gmail.com
Patrick Varilly,patvarilly@gmail.com
Paul Georgiou,pavlos1998@gmail.com
Paul Rabahy,prabahy@gmail.com
Paul Rabahy,PRabahy@gmail.com
Pavel Janík,Pavel@Janik.cz
Pavel Vasin,pavel@vasin.nl
Pavel Vasin,rat4vier@gmail.com
paveljanik,Pavel@Janik.cz
Pavlos Antoniou,antoniou-p@hotmail.com
Pavol Rusnak,stick@gk2.sk
Pedro Branco,branco@uphold.com
Pedro Branco,pedrobrancolcc@gmail.com
peryaudo,peraudo@gmail.com
Peter Josling,peterjosling@gmail.com
Peter Todd,pete@petertodd.org
Petter Reinholdtsen,pere@hungry.com
phantomcircuit,patrick@cloudhashing.com
phantomcircuit,phantomcircuit@debian
phelixbtc,github@blockchained.com
Philip Kaufmann,phil.kaufmann@t-online.de
philsong,songbohr@163.com
Pierre Pronchery,khorben@defora.org
Pieter Wuille,pieter.wuille@gmail.com
Pieter Wuille,pieterw@google.com
Pieter Wuille,sipa@ulyssis.org
poole_party,james@esixteen.co
practicalswift,practicalswift@users.noreply.github.com
Prayag Verma,prayag.verma@gmail.com
pryds,thomas@pryds.eu
pstratem,patrick.strateman@gmail.com
ptschip,peter.tschipper@gmail.com
Puru,tuladharpuru@gmail.com
R E Broadley,rebroad+github@gmail.com
randy-waterhouse,kiwigb@yahoo.com
randy-waterhouse,noone@yodasan
Rav3nPL,rav3n.pl@gmail.com
redshark1802,redshark@gmx.org
regergregregerrge,regergregregerrge@oxymail.de
Ricardo M. Correia,rcorreia@wizy.org
Richard Kiss,him@richardkiss.com
Richard Schwab,mail@richardschwab.de
Richard Schwab,mail@w.tf-w.tf
richierichrawr,richierichrawr@users.noreply.github.com
rion,rion@cs.stanford.edu
Rob Van Mieghem,rob@vanmieghemcloud.com
Robert Backhaus,robbak@robbak.com
Robert McLaughlin,robert@sparkk.us
rodasmith,rodasmith@users.noreply.github.com
Roman Mindalev,r000n@r000n.net
Rose Toomey,rktoomey@gmail.com
Ross Nicoll,jrn@jrn.me.uk
Roy Badami,roy@gnomon.org.uk
Ruben Dario Ponticeli,rdponticelli@gmail.com
Ruben Dario Ponticelli,rdponticelli@gmail.com
Rubén Darío Ponticelli,rdponticelli@gmail.com
Ruben de Vries,ruben@rubensayshi.com
Rune K Svendsen,runesvend@gmail.com
Rune K. Svendsen,runesvend@gmail.com
Russell Yanofsky,russ@chaincode.com
Russell Yanofsky,russ@yanofsky.org
Rusty Russell,rusty@rustcorp.com.au
rxl,me@ryanshea.org
Ryan Havar,rhavar@protonmail.com
Ryan Havar,ryan@moneypot.com
Ryan Niebur,ryanryan52@gmail.com
Ryan X. Charles,ryanxcharles@gmail.com
S. Matthew English,s-matthew-english@users.noreply.github.com
s_nakamoto,s_nakamoto@1a98c847-1fd6-4fd8-948a-caf3550aa51b
Saivann,saivann@gmail.com
sandakersmann,mkjaerstad@yahoo.no
sandakersmann,sandakersmann@users.noreply.github.com
sandos,sandos@sanddesk.(none)
Sanjay Ghemawat,sanjay@google.com
Santiago M. Mola,coldwind@coldwind.org
Satoshi Nakamoto,satoshin@gmx.com
Scott Ellis,sje397@gmail.com
Scott Howard,showard314@gmail.com
Scott Willeke,scott@willeke.com
Sergey Kazenyuk,kazenyuk@gmail.com
SergioDemianLerner,Sergio.d.Lerner@gmail.com
Sev,git@sevastos.com
Shane Wegner,shane-github@csy.ca
shaolinfry,shaolinfry@protonmail.ch
Shaul Kfir,shaul.kfir@gmail.com
Shawn Wilkinson,me@super3.org
Shigeya Suzuki,shigeya@wide.ad.jp
shshshsh,shshshsh@sdsdsdfsd.invalid
Simon de la Rouviere,simon@delarouviere.com
Simon Males,sime@sime.net.au
Simone Madeo,simone.madeo@gmail.com
Sined,nightsbird@gmail.com
sinetek,pitwuu@gmail.com
sirius-m,sirius-m@1a98c847-1fd6-4fd8-948a-caf3550aa51b
sje,sje3000@gmail.com
sje397,sje397@gmail.com
Spencer Lievens,spencerlievens@users.noreply.github.com
spin,spin@ctwug.za.net
Stanislas Marion,stanislas.marion@gmail.com
Stéphane Gimenez,dev@gim.name
Stephane Glondu,steph@glondu.net
Stephen,scmorse@colby.edu
Steven,steven@sigwo.com
Stuart Cardall,developer@it-offshore.co.uk
Subo1978,shuebbel@gmx.de
Suhas Daftuar,sdaftuar@chaincode.com
Suhas Daftuar,sdaftuar@gmail.com
super3,me@super3.org
Suriyaa Kudo,SuriyaaKudoIsc@users.noreply.github.com
Sven Slootweg,info@sven-slootweg.nl
svost,ya.nowa@yandex.ru
tailsjoin,tailsjoin@users.noreply.github.com
Takashi Mitsuta,knhn1117@gmail.com
Tamas Blummer,tamas@bitsofproof.com
Tariq Bashir,tariqbashir@gmail.com
Tawanda Kembo,tawanda@zimstay.com
tcatm,tcatm@gawab.com
Telepatheic,thomas@instantsolve.net
Teran McKinney,sega01@go-beyond.org
TheLazieR Yip,thelazier@gmail.com
theuni,theuni-nospam@xbmc.org
Thomas Holenstein,thomas.holenstein@gmail.com
Thomas Kerin,afk11@users.noreply.github.com
Thomas Snider,tjps636@gmail.com
Thomas Zander,thomas@thomaszander.se
Timon Rapp,timon@zaeda.net
Timothy Redaelli,timothy.redaelli@gmail.com
Timothy Redaelli,tredaelli@redhat.com
Timothy Stranex,timothy@Timothys-MacBook-Pro.local
tm314159,tm314159@users.noreply.github.com
Tom Geller,tom@tomgeller.com
Tom Harding,tomh@thinlink.com
Torstein Husebø,torstein@huseboe.net
Trevin Hofmann,trevinhofmann@gmail.com
tucenaber,tucenaber@gmail.com
tulip,tulip@JBinUp.local
Tyler Hardin,th020394@gmail.com
UdjinM6,UdjinM6@dash.org
UdjinM6,UdjinM6@users.noreply.github.com
unsystemizer,something@gmail.com
unsystemizer,unsystemizer@users.noreply.github.com
Vaclav Vobornik,git@vobornik.eu
Vegard Nossum,vegard.nossum@gmail.com
Venkatesh Srinivas,me@endeavour.zapto.org
Veres Lajos,vlajos@gmail.com
vhf / victor felder,victorfelder@gmail.com
Victor Leschuk,vleschuk@gmail.com
Vinnie Falco,vinnie.falco@gmail.com
Virgil Dupras,hsoft@hardcoded.net
Vitalii Demianets,vitalii@orsoc.se
Warren Togami,wtogami@gmail.com
Whit J,whitj00@users.noreply.github.com
whythat,yuri.zhykin@gmail.com
Wil Bown,wilbown@users.noreply.github.com
Will Binns,binns@21.co
William Yager,will.yager@gmail.com
Witchspace,witchspace81@gmail.com
Wladimir J. van der Laan,laanwj@gmail.com
Wladimir van der Laan,laanwj@gmail.com
wodry,wodry@users.noreply.github.com
xanatos,xanatos@geocities.com
xHire,xhire@mujmalysvet.cz
xor-freenet,xor@freenetproject.org
Yoichi Hirai,i@yoichihirai.com
Yuri Zhykin,yuri.zhykin@gmail.com
Zak Wilcox,iwilcox@iwilcox.me.uk
zathras-crypto,zathrasc@gmail.com
ロハン ダル,rohun-dhar@MN14042102.local

As you can see, there isn't any of the duplication or discrepancy that you posted about. The duplication here comes from different spellings/versions of people's names (e.g. I use Andrew Chow, Andrew C, achow101, or Andrew) and from the same person using different emails.


text:
How does Stellar multi-signing happen practically?
In Blog we read, that Government & NGO came together to sign the transaction, and in docs we read that transaction is invalid if it includes signatures that aren't needed to authorize the transaction and that a transaction envelope wraps a transaction with a set of signatures. But how does the multi-signing process is intended to happen practically?
Let's say I make a transaction that required my and friend's signature, I sign it and publish it. Does it fail because of missing signature? Is my friend notified through stellar that there's a transaction that requires his signature, thus "inviting" him to take a look at it? Can my enemy find it and sign it to deny me contracts? And in case of 20 signers? And in case someone doesn't sign, when does transaction fails? Can he not-sign it in a way to fail the transaction before set expiration time?

The coordination of the tx envelope before it has the right number of signers happens by some other channel. If you and your friend both need to sign for any tx from an account, you would sign it and then email or IM the tx_blob to your friend. Your friend would then add their signature to the tx_blob and submit.
If your enemy signs a tx you can simply remove your enemy's signature before submitting it to the network.
If someone doesn't sign then the server you submit the tx to will reject it immediately.
Source: Multisig and Simple Contracts

Can my enemy find it and sign it to deny me contracts?

Can your enemy find what and sign it?
Either the two transactions are the same or they're different. If they're different, it makes no difference what your enemy does, it's not your transaction. If they're the same, then your transaction must be signed by the enemy too, so why blame your enemy for something you also did?
Until the transaction is properly and perfectly signed, there is no valid transaction, and so absolutely nothing can happen.

And in case of 20 signers? And in case someone doesn't sign, when does transaction fails? Can he not-sign it in a way to fail the transaction before set expiration time?

Until all 20 people sign it, there is no valid transaction, period. Any attempt at submitting anything would fail every time someone attempted it. If he doesn't sign it, whatever transaction you have will fail. You can fail it as many times as you want, nothing will happen. Failure is a non-event -- nothing happens.
Until there is a valid transaction, all that will happen are failures. As soon as there is a valid transaction, it will succeed.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
I imported my private key into blockchain.info but it says 'no free outputs to spend'?
After two days of researching I finally got my private key! However when I import it in Blockchain, it says 'no free outputs to spend'. How do I fix this?

This may sound stupid, but are you sure that you imported the correct address? If you are sure, have you checked on e.g. http://blockexplorer.com that the address did receive the transaction that should have funded it?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Bitcoin Core wallet update schedule and transaction
1) Currently I have Bitcoin Core QT for MS windows 64bit - 32bit version 0.11.2 (yellow one with the most porpularity). Is there any scheduled update of QT to higher version in a near future?
2) I heard from someone that if the Bitcoin Core wallet (same as the above. MS windows 64 bit- 32 bit in yellow color) for each of owner is NOT the same (i.e one has 0.11.0 ver and other has 0.11.2) and receiver's wallet is not synchronized with BTC P2P network, sending BTC from one wallet to other is not feasible and lost permanently. Is this true?

Bitcoin Core 0.12.0 is very close to being released (days).

Different versions of the Bitcoin-qt wallets can most certainly send and receive bitcoins from each other. They are compatible. And it looks like it will stay compatible for the foreseeable future as no hard forks are planned near term.
Just make sure you use the "official" client from bitcoin.org and check signatures to make sure you get the correct one. Also try things with small amounts of money to make yourself comfortable with how it works.
All the other wallets mentioned at bitcoin.org are also compatible regarding sending and receiving bitcoins by the way, but I'm assuming you're interested in running a full node i.e. bitcoin-qt.
Note that this site is not affiliated with bitcoin.org or the core developers (although some of them post here sometimes). I'll clean up your question to better fit the purpose of this website. One way to contact core developers is through the #bitcoin IRC channel.


text:
Bitcoin Core initialization taking forever
Today is the third day, when I'm waiting for Bitcoin Core win-x64 application will sync/initialize. How long should I wait more?

Are you running the latest version? (0.12 is much faster than earlier versions) On decent PC hardware with decent internet connection it should finish well within a day, I think.
On a PC you might want to give bitcoind a bit more memory:
-dbcache=<n>    Set database cache size in megabytes (4 to 16384, default: 100)


text:
Which Two-factor authentication methods are available at which exchanges?
I see that Mt. Gox now supports the Google Authenticator app (on Android, iOS - iPhone, iPad, iPod Touch, and on Blackberry) for 2-factor authentication (in addition to support for Yubikey, of course).
What are all the various 2-factor (also referred to as multi-factor) methods available for Bitcoin-related sites (exchanges, eWallets, mining pools, other services, etc.)?

Good post - "A plea to exchanges ... lets do 2 factor right!": http://bitcointalk.org/index.php?topic=109424.0

Bitcoin Currency Exchanges:

Mt. Gox: OTP using YubiKey or Google Authenticator

Options: [On Login] | [For WIthdrawals] | [For Changes To Security]

Camp BX: OTP/Google Authenticator
Bitstamp: OTP/Google Authenticator
Bitcoin-24: OTP using Google Authenticator and for withdrawal SMS messaging
Bitcoin-otc: GPG authentication with gribble bot
BitMarket.eu: OTP/Google Authenticator
Coinbase - OTP/Authy or OTP/Google Authenticator
FYB-SG (Singapore) - OTP/Google Authenticator
VirWoX - OTP/Google Authenticator
WeExchange.co - OTP/Google Authenticator
BTC-E - OTP/Google Authenticator
Local Bitcoins - OTP/Google Authenticator
bitcoin.de - OTP/Google Authenticator or Yubikey (but not Mt. Gox Yubikey)

Other Exchanges:

MPEx: GPG authentication
ICBit.se: OTP/Google Authenticator
BTC Trading Corp (BTC-TC): OTP/Google Authenticator or YubiKey
BitFunder: OTP/Google Authenticator

Other Services:

BitPay: OTP/Google Authenticator

EWallets:

Blockchain.info/wallet - Google Authenticator, e-mail verification, SMS, and YubiKey (but not Mt. Gox YubiKey).
WalletBit - SecureCard (or perhaps OTP/Google Auth has been added now?)
Coinbase - SMS text messaging-based two-factor, Authy (Android/iOS app similar to Google's)
Paytunia - OTP/Google Authenticator or Yubikey (but not Mt. Gox Yubikey)
bitZino - OTP/Google Authenticator
Just-Dice - OTP/Google Authenticator

Mining Pools:

MaxBTC - Yubikey and Google Authenticator
EclipseMC - Supports Yubi/GA OTP

Blockchain.info also supports "email 2-factor auth". You are sent a code to a predefined email address whenever you try to open your wallet.

Actually, to be extremely pedantic, blockchain.info does not support Yubikey, at least, not properly.

@David would you care to elaborate?

I guess they changed it. They used to support mtgox keys by simply checking the key ID and not the actual OTP which defeated the whole point

Disclaimer: I work for 2FA company CryptoPhoto
Google Authenticator does not save you from phishing or MitM/MitB or malware like NeverQuest, Hesperbot, Zeus, Ice IX, Bugat V2, Carberp,  Citadel, Syscron, SpyEye, etc - or any APTs at all.
In addition:

Google Authenticator (GA) is not open source (only same antique version no longer in use ever got released)
They store their bypass codes in plaintext on the server (any serverside break-in grants the attacker full ability to authenticate as you)
Their bypass codes have insanely low entropy (7 numeric digits only - guessable in a mere 5 million attempts on average)
Their app provides QR code enrollment - and the QR codes are generated by putting your (supposed to be secret) private key into the HTTP GET parameter of a google-owned URL: or in other words - regardless of where you enroll with GA, they're sending your private keys to google.
"HTTP GET" parameters get stored in log files (granting access to your secret keys to anyone who can get the logs - such as by hacking, or legal subpoenas, or intercept)
The GA app uses a 3rd party QR code scanner to read your secret keys.  This 3rd party tool is a supermarket barcode app, designed to send all scanned codes to their server.  This is all "closed source", so it's impossible to tell if they're recording your secret keys.  Even if they're not, the author (which is not Google, and not under their control) merely has to make an update to grab GA keys if he wants.
GA uses TOTP, which works with "shared secrets".  This is a horrifying mistake.  Again - anyone who can crack either end of the channel can forever impersonate the other end (read: a serverside breakin can own your client side auth).  I am gobsmacked google were so stupid on this one.  Asymmetric crypto was invented to stop that kind of problem - did they choose not to use it on purpose ?
In the limited source that's available, there is a race-condition error in their brute-force-prevention code: you're supposed to only be able to guess 3 codes, but if you open 2+ channels for guessing, only 1 of those channels gets blocked - all the other ones can keep on indefinitely guessing new codes without getting blocked.

And of course - to state the bleeding obvious - most of the exchanges that have already been looted were also "protected" by GA, with many of the victim operators publicly announcing that the hackers just bypassed it.
It's cool that GA costs nothing, but that's pretty much all it's worth!

They use 2 Factor ID at ZIGGAP which I found to be one of the best new exchanges out there.

Hello and welcome to the StackExchange. Please keep your answers on topic - singing praises about Ziggapp is tangential to what is being asked. Please specify which two-factor authentication methods are available in the site mentioned.

Moreover, please link it.

ZIGGAP is now ZIGGONE, as in no longer serving customers.


text:
Why do aggregate Schnorr signatures reverse the hash and the random number
A bitcoin signature has:
z = hash(m)

Using a private key pk we can generate a signature for message m
consisting of two numbers: r (x coordinate of the random point R =
k×G) and s = (z+r⋅pk)/k. Then, using our public key P = pk×G anyone
can verify our signature by checking that point (z/s)×G+(r/s)×P has x
coordinate equal to r.

Aggregate Schnorr has:

Call L = H(X1,X2,…)
Each signer chooses a random nonce ri, and shares Ri = riG with the other signers
Call R the sum of the Ri points
Each signer computes si = ri + H(L,Xi,R,m)xi
The final signature is (R,s) where s is the sum of the si values
Verification requires sG = R + H(L,X1,R,m)X1 + H(L,X2,R,m)X2 + …

Why do the hash and the random value swap places in the aggregate Schnorr sig?

I don't understand what swapping you're talking about.

@PieterWuille The z in the first formula is a hash of the message and is added, while the random r is the slope. In the aggregate Schnorr I assume there is a reason for the Hash H to be multiplied by the private key while the random r is added.

Oh, that's just the distinction between DSA and Schnorr. They're very similar, but DSA was designed to avoid the patent on Schnorr signatures.

Schnorr signatures were patented by their creator, Claus Schnorr, and required permission from him in order to be used. The Digital Signature Algorithm (DSA) is similar to the Schnor signature scheme but is made available publicly for free by the US government.
DSA is largely an alternative to Schnorr and needed to be different enough from it so that it would not violate Schnorr's patent. Part of this is different signing and verification formulas.
So what you are seeing is part of the difference between DSA and Schnorr. Bitcoin currently uses DSA over an Elliptic Curve (ECDSA) and the proposed bip-schnorr uses Schnorr signatures over an Elliptic Curve. Thus the differences that you are seeing are because ECDSA and EC-Schnorr are two different algorithms designed to avoid each other's patents.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Is there a list of coins that are bip-32 compatible?
BIP 32 allows me to derive keys based off a root key pair, and all these keys will be on the secp256k1 curve. That means I'll be able to use BIP 32 for other coins that are also based on your curve.
Is there a list of well know coins and the curve they are based on? My spot check shows that most seem to be, but I'm looking for a more comprehensive list

Bip-32 allows me to dereive keys based off a root key pair, and all these keys will be on the secp256k1 curve.

This is actually not true. The BIP32 proposal simply states that (emphasis mine):

In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters defined by secp256k1

In reality, it can be used for any curve, as evidenced by the fact that both Monero and Zcash support BIP32 backed derivations, but use different curves.
If you wish to see a list of coins that follow the BIP32/39/44 system, you can check the coin type list maintained by Satoshi Labs at SLIP-0044

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How do I get set up on Signet?
I have heard about Signet here and here.
How do I get set up on Signet?

Related: https://bitcoin.stackexchange.com/q/17553/5406

I will assume that you want to get set up on the default Signet that is administered by Kalle Alm and AJ Towns. (You can also set up your own custom Signet network and administer it yourself but the following instructions won't apply.)
Signet was merged into Bitcoin Core in PR 18267 in September 2020 and was first included in the 0.21 release.
Build instructions for Bitcoin Core are here (Windows, Mac OS, Linux).
Once you have built Bitcoin Core 0.21 or later you can use the -signet flag to run a Signet node:
bitcoind -daemon -signet

To create a Signet wallet:
bitcoin-cli -signet createwallet "insert_wallet_name"

If you want to play around with Taproot descriptors you will need to create a descriptor wallet. (Unless you specify you want a descriptor wallet it won't create one.)
./bitcoin-cli -signet -named createwallet wallet_name=insert_wallet_name descriptors=true

Then to generate a Signet address:
bitcoin-cli -signet -rpcwallet=insert_wallet_name getnewaddress

At the time of writing (July 2021) this will generate a Signet SegWit v0 bech32 address starting tb1q...
To obtain some Signet Bitcoin there is a Signet faucet here: https://signetfaucet.com/
You can track Signet transactions with the Signet block explorer here: https://explorer.bc-2.jp/
You can run a Signet node in parallel with your mainnet node like you can with a testnet node.
For more details see Kalle's workshop at Advancing Bitcoin 2020 that shows you how to make Taproot transactions on Signet and debug Taproot scripts using Kalle's Bitcoin script debugger btcdeb. (Beware that the workshop is from before Signet was merged into Bitcoin Core, so some of the details are outdated.)
There is a list of signet resources in this issue from openoms.


text:
My first full node - no bitcoin.conf
So I am in the process of downloading the blocks after installing bitcoin on my ubuntu server. I have followed the guide on https://bitcoin.org/en/full-node.
Everything is working correctly. Blocks are downloading just fine to ~/.bitcoin/blocks. bitcoin-cli commands are working without error.
If I switch users and I try to issue a bitcoin-cli command naturally I get "Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set."
However when using the correct user where cli commands do work, there is still no bitcoin.conf file inside ~/.bitcoin/ As the node is downloading the blocks and the cli commands work I assume there must be a conf file - yet its not where every single document and support answer claims it will be.
I have tried find . -name "bitcoin.conf" in the ~/.bitcoin directory as well as user ~/ and in /etc all return empty. Where else could this file possibly hide? If it doesn't exists why would I still be downloading blocks and able to issue cli commands?
I am aware this question has been asked countless times but i cant find any answers relating to the fact the node is working and cli commands are working.

With the user where bitcoin-cli does work, you can try running strace bitcoin-cli getblockchaininfo and read the output to see which path it is reading bitcoin.conf from. For example, I can see openat(AT_FDCWD, "/home/ubuntu/.bitcoin/bitcoin.conf", O_RDONLY) = 3 in my local output.

well now i am super confused as that returns open("/home/admin/.bitcoin/bitcoin.conf", O_RDONLY) = -1 ENOENT (No such file or directory) and yet i can still issue commands like bitcoin-cli getnetworkhashps and bitcoin-cli getblockchaininfo without any errors.

Do you have a /home/admin/.bitcoin/.cookie file?

yes i do have ha file, i has a single line in it

When you don't explicitly specify any RPC credentials, bitcoind will autogenerate them for you and store the password in the $DATADIR/.cookie file.
You can then use the username __cookie__ along with the password from that file.

Note that the contents of that file will change every time you restart Bitcoin Core. If you have a need for accessing your bitcoind in any setting other than the local user with bitcoin-cli, you should really create a bitcoin.conf file with a static username/password (look up rpcauth).


text:
how does one map a transaction number to a block with just the bitcoind client?
I realize this can be done at blockchain.info, but would like to find a way to do this with just the bitcoind client. if all I have is the receiving address and the transaction number, I can't figure out what command or set of commands to use. I can get and decode the raw transaction (bitcoind decoderawtransaction $(bitcoind getrawtransaction 3dd264f603f75871c5a36b61db8e137d8cee6b019a8d5bdfdabd7383ccc47068) | less), but that doesn't give me the block number.
note that I can't use gettransaction because my local box (netbook) isn't the origin nor the destination of the transaction; I get error: {"code":-5,"message":"Invalid or non-wallet transaction id"}. I also can't use listreceivedbyaddress for the same reason, although I don't get an error in this case because I did once send to the address in question from my netbook.

note to people coming across this question: don't mark down Luca's answer, I hadn't made it clear at the beginning that I couldn't use  gettransaction. added that  in just now.

This may be impossible to do without looking up each block down until you get to one that contains it.

yeah, I'm beginning to think that's probably my only option. I guess that's what blockchain.info does too, just loads all the blocks into a database.

If you're good with Javascript this can be done easily with Bitcore. It's really interesting and powerful.

figured it out after finding my own previous post about how I found out this info with americancoind, coin seems to have gone to a duplicate address, by its error message on attempting to resend the raw transaction. but bitcoind doesn't tell you what block it's in, merely stating error: {"code":-5,"message":"transaction already in block chain"}. however, on searching through the source (rpcrawtransaction.cpp) I noticed that getrawtransaction takes an extra arg, verbose, which if greater than 0 gives the blockhash:
jcomeau@aspire:~/rentacoder/jcomeau/bitcoin/src$ bitcoind getrawtransaction 3dd264f603f75871c5a36b61db8e137d8cee6b019a8d5bdfdabd7383ccc47068 1 | grep block
    "blockhash" : "000000000000000116f3abab7d0f620f620eae189de29ddb06fe8baae566467a",
    "blocktime" : 1393013064

and with the blockhash you can use getblock:
jcomeau@aspire:~/rentacoder/jcomeau/bitcoin/src$ bitcoind getblock 000000000000000116f3abab7d0f620f620eae189de29ddb06fe8baae566467a
{
    "hash" : "000000000000000116f3abab7d0f620f620eae189de29ddb06fe8baae566467a",
    "confirmations" : 255,
    "size" : 341358,
    "height" : 287092,
    "version" : 2,
    "merkleroot" : "d0fd6154ba64682b48c9c15600ee7c8594336cf4c0a2917b5cbcf1f5a74d2096",

so, 287092 is the block number that contains the transaction.


text:
Btc in my hard drive
I really need some help.
So as you know, BTC is out there, and I recall at the beginning of 2015 when it was really not a big deal, I decided to get learn more about btc and somehow I downloaded a type of software in my laptop that allowed me mine BTC now, my laptop ran for days and really I thought it was not a good idea  i decided to cancel the process, but somehow it looks like I mined some btc, now my laptop got really full on space  so i took it to the apple store and they figured out what happened,this happened at the beginning of this year 2017, I had an external hard drive and i put all those codes, blocks, pages however they may be call into the folder and they genius guy told me that i may havce some good money there bc it was a lot.
now, with that story put out there, my question is; how can i transfer those things from my external hard drive to a physical btc wallet? so i can somehow enjoy it.
any advice will highly appreciated it.

mining with a Laptop, even with the graphics card, shouldn't provide you with a fortune. But if you want to dive deeper, maybe check for a file called wallet.dat. Assuming you had bitcoin qt (core software) installed. You can search for it in finder. Or you press left ALT key, and chose in finder "goto" menu -> Library. There is "Application Support", and maybe a bitcoin folder. Check the forum here for the tag "wallet", and search for OS X. Or the tag "wallet-recovery". There are many posts. And let us know, how it goes :-) Maybe tag your post also with "wallet-recovery".

Nope. PC mining became unprofitable in ~2014 so you may not have mined bitcoins.
What you probably did was downloading Bitcoin Core and synchronising it (downloading and storing all the Bitcoin transactions)
Sorry, but you probably haven't earned bitcoins.

(1) mount and symlink that external drive's .bitcoin folder to $HOME/.bitcoin.
(2) run bitcoind. get your balance with bitcoin-cli getbalance. if it's anything above 0.00000000 then come back for advice.


text:
Parse UTXO of a transaction from chainstate
I'm doing some analysis on the UTXO set by reading from the chainstate database.
I was following the documents given by https://github.com/bitcoin/bitcoin/blob/d4a42334d447cad48fb3996cad0fd5c945b75571/src/coins.h#L19-L34
/** pruned version of CTransaction: only retains metadata and unspent transaction outputs
 *
 * Serialized format:
 * - VARINT(nVersion)
 * - VARINT(nCode)
 * - unspentness bitvector, for vout[2] and further; least significant byte first
 * - the non-spent CTxOuts (via CTxOutCompressor)
 * - VARINT(nHeight)
 *
 * The nCode value consists of:
 * - bit 1: IsCoinBase()
 * - bit 2: vout[0] is not spent
 * - bit 4: vout[1] is not spent
 * - The higher bits encode N, the number of non-zero bytes in the following bitvector.
 *   - In case both bit 2 and bit 4 are unset, they encode N-1, as there must be at
 *     least one non-spent output).

The parser worked fine when the number of UTXO is small. However for the following tx (which have 2501 outputs), it failed:
2540b961f4a0b231db3bc5a23608307394eae037d8afd0462e9b794e02f00000

For the key 'c' + 2540b961f4a0b231db3bc5a23608307394eae037d8afd0462e9b794e02f00000, the (deobfuscated) value in chainstate looks like this:
01907050e140254150443a0c280004...

Where 01 is the version, 9070 is the nCode which tells if its a coinbase tx, the unspentness of vout[0], vout[1], and the length of the following unspentness bitvector for vout[2:]. By looking at blockchain.info, there are 2501 outputs, so there shall be (2501 - 2)/8 = 312 bytes following. However, parsing 9070 as a varint, removing the last thee bits, and +1 only give me 2288 / 8 + 1 = 287. (I got 2288 by (0x90 - 0x80 + 1) * 0x80 + 0x70, which is the MSB-128 varint used in bitcoin protocol.)
Did I missed something here? How exactly does one parse the varint?

You are right, however you are not interpreting the result correctly. The value is indeed 287, that is (2288 >> 3)  + 1, however this does not mean that the bitvector contains 287 bytes, but that it contains 287 non-zero bytes, so when parsing the bitvector, you should decrease the byte counter only when you find a non-zero value. Here you have a piece of code that deals with this (n is 287 in this case):
# If n is set, the encoded value contains a bitvector. The following bytes are parsed until n non-zero bytes have
# been extracted. (If a 00 is found, the parsing continues but n is not decreased)
if n > 0:
    bitvector = ""
    while n:
        data = utxo[offset:offset+2]
        if data != "00":
            n -= 1
        bitvector += data
        offset += 2

Notice that this is just a fragment of the code. I've coded a full decoder in Python recently, you can check out the code on github.

Hmm, that make sense. I've read lots of questions and answers by you on this topic. Thanks so much!

May I also ask how are CTxOuts serialized? I get that most of it are of the form CompressedAmount + 00 + hash160 of pubkey, but there are lots of nonstandard transactions which are hard to parse.

https://github.com/bitcoin/bitcoin/blob/v0.14.1/src/compressor.h#L17L27

It is also part of the code I've linked in the answer, let me extend the answer to include that part of the code (check the comments)

Found it, thanks. https://github.com/sr-gi/bitcoin_tools/blob/d679c41183e315686729ca6b8bd79c7daa499b4d/utils/utils.py#L363-L388

Exactly, there it is.


text:
What is the Bitcoin equivalent of /dev/null?
Which canonical address is a legitimate address that nobody can claim?

Possibly related - http://bitcoin.stackexchange.com/a/1852/323

Probably this address would be pretty acceptable - 1111111111111111111114oLvT2. It has a RIPEMD-160 hash of 0000000000000000000000000000000000000000.

Don't forget that there are roughly 2^(256-160) private keys for each bitcoin address, so it's very unlikely that none of them correspond to the address you specified, meaning that the coins are in all likelyhood claimable.

@ChrisMoore I believe 0x0 is an invalid public key, which would make it impossible to find a matching privkey.

@DavidPerry OK, but we don't send bitcoins to public keys; we send them to 160 bit hashes of public keys.  Any private key whose public key has the same 160 bit hash can claim the funds.  There are likely a massive number of private keys that are able to claim funds sent to 1111111111111111111114oLvT2.  It's just almost impossible to find any of them.

@ChrisMoore I see your point. It's statistically possible that some address exists which has no possible valid privkeys but every time I try to come up with a way of finding such an address the phrase "computationally unfeasible" comes to mind with it :P

Just make up any 160 bit number and convert to an address then.  They're all impossible to spend from unless you already know a private key for them, or get very very (very) lucky and find one.  As for canonical, which definition did you mean?  "authorized; recognized; accepted: canonical works" or
"Mathematics . (of an equation, coordinate, etc.) in simplest or standard form."  The 'BitcoinEater' one is probably most recognised.  The 0x0 one could be argued to be simplest.

@ChrisMoore This is incorrect; "in all likelihood" is inaccurate. If your claim was true, then this would apply to any existing bitcoin address. In fact, the probability of generating a private key for that address at random is 2^(-160), which is definitely computationally out-of-reach. This is comparable with the 2^(-128) probability of randomly guessing an AES key.

There is probably no bitcoin address that nobody can theoretically claim, since so many different private keys (256 bit) map to each bitcoin address (160 bit).
It has been proposed that 1BitcoinEaterAddressDontSendf59kuE should be used to destroy unwanted bitcoins.

What do you mean by "nobody can theoretically claim"? What is your "theory" here? Because if you use any reasonable theory for polynomial computational abilities, no, polynomial agents cannot claim these addresses (given we key the private and public addresses correctly). This is the same theory that supports, for example, the unbreakability of RSA and ECDSA.
Specifically, for practical purposes, as you mention bit sizes, you'd need to brute-force a space of 2^160 which is impossible. The fact that the private key space is larger is insignificant.

The address 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh is a valid address made from an invalid public key which certainly qualifies as an effective /dev/null
It seems that the address was created by a bug in one particular wallet software.
By the way, don't burn money, it is the epitome of the old saying, "A fool and his money are soon parted."
rel:
Invalid public key was spent! How was this possible? (it wasn't, actually)

The funds of the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM can't be spent. Why? What makes it different from other addresses?

 The private key is zero. ECDSA private keys must be greater than zero. If not, funds of that address can't be spend.

Why do they must be greater than zero? Is that only on Bitcoin as a rule or in general it cannot be 0 because of the math behind?


text:
Are there proposed hardfork changes that couldn't be made if the market was filled with ASIC miners?
Suppose a year from now most of the hashrate is being produced by ASICs.
Bitcoin is not feature-complete yet. Out of the changes in the hardfork wishlist, would any of these changes be hard/impossible to implement on ASICs that have been sold already?
To make such breaking changes, it most likely that a majority of the mining power will be needed. If ASICs become the majority, and they can't adjust to these changes, do we have a problem?

I say "most likely we need a majority" because maybe breaking changes could be done without a majority of hash power, but rather a near-majority, accompanied by strong user support. But it would certainly make life more complicated.

As long as no changes are done to the structure of the block header, the ASICs should work just fine. There are some proposed changes that could alter it, like protecting the block chain against pre-mining, or adding a new field to the block header.
So yes, when the ASIC miners become the majority it will be hard to push those changes unless Bitcoin faces some serious issue that forces the change (for example, an attempt at a 51% attack).

What do you mean by "adding some header three" ?

@ripper234 I think he meant "there" not "three".  I've edited the whole answer to try to make it more understandable.

@ripper234 Sorry, I meant "header tree".


text:
Deterministic keys with one-way operation
BIP 0032 "Security Implications" states

One weakness that may not be immediately obvious, is that knowledge of
  a parent extended public key plus any non-hardened private key
  descending from it is equivalent to knowing the parent extended
  private key (and thus every private and public key descending from
  it).

From what I understand, the weakness is due to the reversible nature of the operation on extended public key (addition). Wouldn't it be possible to address this by using a one-way function like hashing instead of addition?

If you use a one-way hash function (ie like hashing ECDSA public key with SHA256/RIPEMD160 into a hex public key) then how can you employ hierarchical deterministic functioning?
You can't. The whole point here is that if you lose your private key for a grandchild public key you can get it back again with the parent key. A two-way hashing function obfuscating the data would work but that's basically what's already in place.

can you help me understand why hashing wouldn't be deterministic? I'm guessing something like sha256(extended_private_key, offset) where offset is 1...n could result in n deterministic keys

I may be wrong, but if the hash has no predictable outcome, then adding an offset to the random number is just saying random hashed output + offset, or more simply (since we ignore the random part) offset, which is what we have already with HD wallets. Hashing the offset is the only way but then how do you get it back? If there's a take home point it's that there is no way to predict a hashed output, and if there were, the encryption would be poor. Hashed output would be impossible to detect the offset added to it.


text:
Help running cgminer on Ubuntu 14.04 - waiting for USB hotplug devices, and other errors
I'm a total noob regarding bitcoin mining, I've installed cgminer using apt-get install but I can't get it to work.
I start it with this command:
./cgminer  -o stratum+tcp://www.albamine.net:3333 -u Weblogin.WorkerName -p WorkerPassword

I followed these instructions:  (I'm mining for scotcoin.)

Install Ubuntu
Install updates
sudo apt-get update
Install updates for your graphics card
Install misc packages
sudo apt-get install gedit git libcurl4-openssl-dev libncurses5-dev pkg-config automake yasm
Edit grub configuration
sudo gedit /etc/default/grub
  Edit GRUB_TIMEOUT=10 to GRUB_TIMEOUT="10"
sudo update-grub
Download ATI OpenCL drivers. Untar it and run the script inside.
Reboot.
git clone git://github.com/ckolivas/cgminer
Download the ADL SDK. Unzip it. Copy the include directory into cgminer, and name it ADL_SDK
Check dependencies for cgminer.
  cd ~/cgminer
./autogen.sh
Create the build script:
  CFLAGS="-O2 -Wall -march=native -I /opt/AMDAPP/include/" LDFLAGS="-L/opt/AMDAPP/lib/x86_64" ./configure
make
Run using
  export DISPLAY=:0; export GPU_USE_SYNC_OBJECTS=1; ./cgminer -n

The first few times I tried I got an error that repeatedly said:
KnC spiL Can not open SPI device /dev/spidev1.0: No such file or directory.

NowI'm getting a terminal that looks like this, and I have no idea. I've googled select sections of the code but can't figure out what it's all about. Any suggestions would be gratefully received. Thanks.

Info. Running Ubuntu 14:04 on a System 76 Galago Ultra pro.

Your system reports: Intel's new Iris Pro graphics.
As far as ubuntu 13.10 was concerned the package cgminer was compiled for nvidia graphics cards and installed the module for ubuntu.
Consider running a system with dedicated GPU w/ PCIe: e. g. nvidia and ATI and possibly compile cgminer by yourself.
I tried bfgminer for ubuntu now, see here: http://jarco.be/install-bfgminer-ubuntu-mint/
...but cannot get it to work for litecoin scrypt right now...
NOW up and running bfgminer compiled for ubuntu 14.04 with howto from here:
https://debianhelp.wordpress.com/2012/01/02/bitcoin-mining-in-ubuntu-with-bfgminer/
with some minor changes:

installed "bitcoin-qt" instead of "bitcoin"
sudo apt-get install uthash-dev
./autogen.sh && ./configure --enable-scrypt --enable-opencl && make
modified ".bfgminer/bfgminer.conf" can be pasted here, if you want
-> 880kh/s @ ATI Radeon R9 290X

Oh I see, it looks like mining for scotcoins might be more involved than I'd expected. I'd hoped it would be the sort of thing I could've done using spare processing power when my laptop isn't busy! Thanks for enlightening me!

Furthermore the cgminer versions mentioned on your getting started page are outdated, there is only 4.x available. And these versions do not support GPU mining at all (Con Kolivas writes):
Q: What happened to CPU and GPU mining?
A: Their efficiency makes them irrelevant in the bitcoin mining world today
and the author has no interest in supporting alternative coins that are better
mined by these devices.


text:
Unable to open Backup binary file Linux
I recently reinstalled Linux mint; I backed up my wallet, and I am unable to import the backup created from the original wallet (Qt version 4.8.6.) to the newly installed wallet(Qt version 4.8.6.) I have just installed. When I try and open up the backup (binary file) using Bitcoin-QT a textbox appears with the message:

Payment request file can not be read or processed! This can be caused by an invalid payment request file.

Can anyone help with this please? Or, just point me in the right direction.

I'm just learning Linux so I'm only able to help in the capacity of saying look into how the blockchain is bootstrapped using torrent. There's a trick like a detachdb flag or similar. It sounds like a blockchain issue

-detachdb was removed in v0.8.0 as we no longer need it (the block databases now uses LevelDB, which is always portable).

To restore a backed up wallet.dat file, you need to replace it manually.
Just overwrite the one in your data directory (see https://en.bitcoin.it/wiki/Data_directory to find it for your platform).
Opening the file with Bitcoin-Qt means you're trying to process a payment request; it's not for opening a wallet.

This is correct. Close the Bitcoin software, then for the majority of installs in a terminal run 'cp /path/to/your/backup/wallet.dat ~/.bitcoin/'. Now open bitcoin-qt again.

You can try the command in your shell: bitcoin-qt -rescan  It will rescan the block chain for missing wallet transactions.

Please don't suggest using -rescan. It's only necessary if you manually edited the wallet file these days; rescanning is otherwise always automatic.


text:
How do I find the txid and vout values for an input I want to spend?
I was in the http://coinb.in/multisig/#newTransaction and wanted to make a input but it needed 2 values.

Txid, How do I get that?
TxIn/vout, Whats that and how do I get that?

If you want to send some coins, you have to have been given some coins before.
When someone sends coins to you, they make a new transaction. This transaction has a TxID (which is the double SHA256 hash of the raw transaction bytes) that everyone uses to refer to this transaction. A transaction can have multiple outputs, and each outputs allocates some of the previously unspent transaction outputs (UTXO) that were used as inputs in the new transaction.

So, really this question comes down to: what are bitcoins? Bitcoins are a pair of TxID and an index that uniquely specify an entry in the blockchain.
The developer documentation (https://bitcoin.org/en/developer-documentation) goes into great detail if you want to learn more.
As far as how do you actually get your hands on these values, you just have to have someone send you coins to your address (or mine them), and then you could just look your address up on a blockchain explorer and find any unspent outputs it has. From there, you can just use the web interface to see the txid and the output index. For example, I just grabbed a random transaction off from blockchain.info at https://blockchain.info/tx/86e06fed6f597dc212e72556a84660d84e9536e081719624a0a30a685238d0d7. You can see the txid is 86e06fed6f597dc212e72556a84660d84e9536e081719624a0a30a685238d0d7 and that there are two outputs (indices 0 and 1), the first of which has been spent, and the second one which has not been spent (at the time of writing).

But how do I get Txin thats the real mystery

Txin/vout is just the index of the previous transaction output that you are spending. So in the example I gave, Txin/vout is 0 or 1, depending on which ouptut you are trying to spend.

So how do I get it?

Find the transaction that was sent to an address that you own on a block explorer, such as blockchain.info, and look at which output has your address in it. The first output has txin/vout 0, the second has txin/vout 1, etc...

How do I find the transaction id (txid) with  a address by local bitcoin node, the address maybe not inside my wallet?

@FrankAK some wallets supports the RPC call "getaddressutxos"
Returns all unspent outputs for an address (requires addressindex to be enabled).


text:
NoClassDefFoundError when using Java Coinbase API
I've simply downloaded an API .jar file of a Coinbase. I've created a project dynamic web project. I added successfully into a reference library that API.
Here is my simple program:
import com.coinbase.api.Coinbase;
import com.coinbase.api.CoinbaseBuilder;

public class Main {
    public static void main(String[] args){

        try {

            Coinbase cb=new CoinbaseBuilder()
            .withApiKey(System.getenv("My API KEY"), System.getenv("MY API SECRET"))
            .build();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

As i run this program, it says:
Exception in thread "main" java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/type/TypeReference
    at com.coinbase.api.CoinbaseBuilder.build(CoinbaseBuilder.java:16)
    at Main.main(Main.java:11)
Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.core.type.TypeReference
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    ... 2 more

Do I need to put something here? I'm did checked thrice, My API key is correct!

@GeorgeKimionis I disagree. It would probably be better asked on another site, but I don't think it's offtopic.

@GeorgeKimionis However, thanks for finding that link. That could probably be an answer if you quoted one of the answers on that page.

Well the problem is that the Coinbase Java Api depends on the Jackson JSON processor, along with several other dependencies that can be found here, and I'm assuming that the jar that you download didn't come with all of these dependencies packaged inside it which means that they won't be on your classpath just because you've added the coinbase jar. You could either try to resolve these dependencies manually, which would be incredibly tedious and unnecessary, or you could use a build automation tool. Considering that the Coinbase Java API was built with it in mind I would recommend setting your project up to use Maven.

authors: Александр Валериевич


text:
Is BIP analogous to RFC?
It seems that a BIP (Bitcoin Improvement Proposal) is very similar to an RFC (Request for Comments). Can anybody confirm this, or describe major differences in the two approaches?

BIP's and RFC's are similar in that they

debate an implementation in the community in order to improve it, and
produce documentation that's useful to other coders.

However, they're different in a lot of other ways. This is largely because the two solve different problems: RFC's usually invent new protocols, whereas BIP's amend an existing system.
Other differences:

An RFC with a specific serial number always refers to a specific version of that document. If the RFC changes (and the change isn't something tiny, like spelling), it is assigned a new number.
On the other hand, a BIP is expected to go through multiple major revisions in the Draft stage. Changes are instead tracked through version control.

The RFC approval process and the BIP approval process are different.

RFC's have authors, BIP's have champions. This isn't just a difference in terminology. The champion of a BIP needs to convince other people that it's a good idea before it will be accepted, whereas the RFC process is much less restrictive.

See also:

Who specified the Bitcoin protocol?
How is a BIP accepted?


text:
Are there any hardware privkey/pubkey generators out there?
I don't mean hardware wallet like Trezor but simply a device that is non-programmable, and not network connectable but will generate key pairs (+ the associated address would be handy but that could be done in software on only the pubkey without too much risk?) at the push of a button.
I'm wondering if this is one way to create a paper wallet and have it receive a number of BTC:
1.Generate a privkey/pubkey pair
2.Write the privkey down, duplicate it and store the copies safely. I guess this could potentially be split into pieces and stored in several separate places so that breach or loss of one does not give away the full privkey or lose the information needed to recreate it (like a paper RAID array implemented with three familiy members?) [and write recovery instructions in your testament]
3.Generate the bitcoin address associated with the pubkey (not so risky, afaict)
4.Receive the payment at this address
Until it comes to spending the BTC (which could be quite some time in the future) there would be no need for a software wallet, and certainly no need to use an online key generator.
In the absence of a hardware key generator I suppose downloading trusted code from sourceforge or somewhere and running it yourself on a non-networked computer is pretty much as secure?
(I realize rolling dice is fine to generate a privkey but the associated pubkey pretty much has to be done in code somewhere, no?).
Does this sound feasible?

There are no devices I know of which are dedicated to nothing but generating secp256k1 key pairs.  I suspect there never will be---that's a super-niche market possibly consisting of just you.  Moreover, I think you should be suspicious of any hardware designed to generate private keys for Bitcoin: corrupting such hardware to produce predictable keys could be highly profitable---at your expense.
In general, messing around with private keys directly has a high probability of ending in lost bitcoins.  A $50 USD used netbook from eBay to use as an offline signing-only wallet will be much easier to use and at least as secure as any system you think up yourself, provided you choose a secure wallet.

thanks, I see your point. That said Trezor is hardware desgined specifically to generate key pairs with a little more added on, is it not? The brand has much to lose if it's found out that something untoward has happened but that could be nothing compared to the gains. I have a Trezor and there's no reason to believe the company is anything but honest but I don't see a that big of a distinction between the two cases.

The offline signing-only wallet sounds useful, thanks for the pointer. We're still putting our trust in someone by selecting the "secure wallet" to use but I can see the logic.

Trezor's main purpose is secure signing, and it mostly derives key pairs from a seed rather than generating them from a random number.  I have reasonable trust in the public faces of Trezor, but I don't know anything about the people who designed the hardware, manufactured the hardware, or delivered the hardware---and any one of them could've changed the specs in a way that's very hard to detect.

There is Piper Wallet.
And Bitfrore is in the works.
Both are self-contained devices which generate and print private key and address pairs.

I've read that Verso is "... also working on a system to allow users to create the public/private key(s) offline for security." (see https://axablends.com/merchants-accepting-bitcoin/bitcoin-wallets/verso-cards-bitcoin-cold-storage-for-everyone/), though I can find nothing on the Verso website yet (12/11/14) to back this up (not saying I would use it!)
https://versocards.com/ - their cards look interesting and don't require two computers but instead use a card encoded with your private key that is scanned by a mobile phone app that actually recreates the key to use for spending. It appears to be a single address/pubkey/privkey system though, from what I can tell.
offline capable wallets:
https://bitcoinarmory.com/
https://electrum.org/index.html


text:
Slow sync running Bitcon full node on Mac Mini OSX
It is Jul 2018, I need help after several attempts to sync a full node running on a Mac Mini.
I have tried several times and Bitcoin-qt starts pretty well for the initial sync, downloading with progress that ranges from 1% per hour up to 3 % per hour. But when sync goes around 30% (blockchain around 50 GB) sync slows down to 0.2% per hour so it'd take weeks.
HARDWARE:

1.4GHz dual-core Intel Core i5
OSX 10.13.6
500GB (5400-rpm) hard drive
RAM 4GB of 1600MHz LPDDR3 memory
Good internet speed.

SOFTWARE:

Installed Bitcoin Core implementation 0.16
I tried both, installing the .dmg for mac and also tried to homebrew
Both successful in the beginning, and then sync goes down

I get good connections, and I have the port 8333 opened so I have no clue of what is going on, whether it is problem with the hardware (mac works fine) or the implementation.
Actually I have been running Litecoin and Monero nodes in the same hardware, implementing OSX builts and those worked fine, but Bitcion Core doesn't .
I hope someone can help me, if faced the same difficulties with bitcoin.
I really would like to succeed in this and support the network

The hardware and the disk are the limiting factors. I had two mini Macs (32 and 64 bit) and a RasPi, and could repeat the scenario several times. I also installed SuSE Linux and OpenBSD, changed parameters, looked at disk I/O and CPU load.
The blockchain is currently +160 Gig, with many blocks and transactions. As the initial sync starts from the very first block, each block and. Each transaction inside a block is verified. A transaction consists of inputs, which references previous transactions. This creates much of the disk activity. An SSD can speed up this process dramatically.
At the beginning, the blocks were nearly empty, but nowadays they are full. So the process to load blocks is rather quick at the beginning, and slows down when it comes to mid 2017...
Then there is the CPU. A dual core Intel has some work to do, to get the Crypto work done. And it has to wait for the disk to provide data (when loading goes high, mostly above 4 all the time).
I couldn‘t put my MAC Mins into the trash, and decided to go with the blockchain. It took 3 weeks on 2017 to load the whole blockchain (with 5400rpm HDD). So really need to think, if time is an issue, or if more powerful Hardware shall do the trick.

Syncing the bitcoin blockchain on lower-end hardware takes it's time. Just let it run.