Alan Reiner, Founder and CEO, Armory

Bitcoin Lead Developer Gavin Andresen on Origins, Expectations, Projects & Pitfalls. Alan Reiner of Armory Wallet, Bitcoin powered Tor & Wi-Fi Nodes, And Feathercoin Lead Developer. Catch it all here for Let's Talk Bitcoin! Episode 015

submitted by internationalaw to Bitcoin [link] [comments]

Alan Reiner from Armory - Best Practices for Using and Securing Bitcoin

Alan Reiner from Armory - Best Practices for Using and Securing Bitcoin submitted by pmelt to Bitcoin [link] [comments]

Intro to Bitcoin Security with Alan Reiner

Intro to Bitcoin Security with Alan Reiner submitted by Jachoshi to Bitcoin [link] [comments]

Alan Reiner from Bitcoin Armory discussing mulit-sig Lock boxes

Alan Reiner from Bitcoin Armory discussing mulit-sig Lock boxes submitted by Kupsi to Bitcoin [link] [comments]

Interview: Alan Reiner from Bitcoin Armory discussing mulit-sig Lock boxes

Interview: Alan Reiner from Bitcoin Armory discussing mulit-sig Lock boxes submitted by BitcoinVideo to Bitcoin [link] [comments]

CoinTalk Episode 11 - Inside Bitcoins Las Vegas 2013 - Guests include: Ron Gross - Mastercoin, Joshua Schechter - Crypto Trust Point, Alan Reiner - Armory Technologies, Hieu Bui - BitDazzle - Enjoy!

CoinTalk Episode 11 - Inside Bitcoins Las Vegas 2013 - Guests include: Ron Gross - Mastercoin, Joshua Schechter - Crypto Trust Point, Alan Reiner - Armory Technologies, Hieu Bui - BitDazzle - Enjoy! submitted by COINTALK to Bitcoin [link] [comments]

MIT Bitcoin Expo video is up!

MIT Bitcoin Expo video is up! submitted by SaadRhoulam to Bitcoin [link] [comments]

List of Bitcoin services that support/oppose increasing max block size

Now that the topic is again on the surface, I'm reposting my previous analysis. I'm also happy to update it.
Bitcoin companies and their services are an important layer of the Bitcoin ecosystem. They have a great understanding of Bitcoin technology, just like the devs, but their perspective is different. Let's see what they think.
Please inform me of any relevant opinions that I'm missing. I only want clear opinions, not borderline ones. Also, only opinions of companies clearly working with Bitcoin itself. And please only services that are currently operational.
PRO
Coinbase & CEO Brian Armstrong https://twitter.com/coinbase/status/595741967759335426 https://twitter.com/brian_armstrong/status/595453245884997634
Blockchain.info Co-founder Nic Cary & CEO Peter Smith https://twitter.com/niccary/status/595707211994763264 https://twitter.com/OneMorePetestatus/595676380320407553
BitPay CEO Stephen Pair https://twitter.com/spaistatus/595341090317799424
Xapo CEO Wences Casares https://twitter.com/wences/status/595768917907402752
Third Key Solutions CTO Andreas Antonopoulos https://twitter.com/aantonop/status/595601619581964289
Armory CEO Alan Reiner http://sourceforge.net/p/bitcoin/mailman/message/34093337/
Bittiraha.fi & CEO Henry Brade https://twitter.com/Bittirahafi/status/596682373028311040 https://twitter.com/Technom4ge/status/596334370803326978
Kryptoradio creator Joel Lehtonen https://twitter.com/koodilehto/status/596675967667568641
BX.in.th https://twitter.com/BitcoinThai/status/605022509101023232
Jameson Lopp, BitGo engineer https://twitter.com/lopp/status/605041173439209472
Breadwallet CEO Aaron Voisine http://sourceforge.net/p/bitcoin/mailman/message/34096857/
OKCoin https://twitter.com/okcoinbtc/status/598412795240009728
BTC Guild founder, Eleuthria https://www.reddit.com/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3
AGAINST
MPEx http://qntra.net/2015/01/the-hard-fork-missile-crisis/
GreenAddress http://www.reddit.com/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84
Bitcoinpaygate http://www.reddit.com/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp
Bitrated founder Nadav Ivgi https://twitter.com/shesek/status/605005384026177537
David Francois, CTO of Paymium http://fr.anco.is/2015/gavineries/
submitted by Technom4ge to Bitcoin [link] [comments]

WARNING: A fake electrum website with malware is advertising on duckduckgo and yahoo.

If you perform a search for electrum on duckduckgo or yahoo, an ad claiming to be electrum.org will be at the top.
In reality the ad links to: electrum-bitcoin org
The domain was created December 21.
This site is nearly identical to electrum.org except the download links give different files. All three of the files that can be download are much smaller than the real electrum and are most likely malware. The three files are: electrum.exe - 91136 bytes electrum.out - 60316 bytes electrum.zip - 32478 bytes
EDIT: Some Advice:
When installing software, especially something as import as wallet software, it is a good idea to verify the integrity of the download with a signature using a key that was obtained from one or more seperate sources.
I made a list of the keys used to sign popular bitcoin wallets below to act as another source to verify the integrity of those keys.
Bitcoin-Qt: Signer: Gavin Andresen [email protected] Fingerprint: 2664 6D99 CBAE C9B8 1982 EF60 29D9 EE6B 1FC7 30C1 Key ID: 1FC730C1 Key Link: bitcoin.org/gavinandresen.asc
Electrum: Signer: ThomasV [email protected] Fingerprint: 6694 D8DE 7BE8 EE56 31BE D950 2BD5 824B 7F94 70E6 Key ID: 7F9470E6 Keyserver: pool.sks-keyservers.net
Multibit: Signer: Jim Burton (multibit.org developer) [email protected] Fingerprint: 299C 423C 672F 47F4 756A 6BA4 C197 2AED 79F7 C572 Key ID: 79F7C572 Keyserver: pgp.mit.edu
Armory: Signer: Alan C. Reiner (Offline Signing Key) [email protected] Fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 Key ID: 98832223 Keyserver: pgp.mit.edu
The signatures provided for some of the wallets are signatures of the hash values, so be sure to verify that the hash of the downloaded file matches the hash that was signed.
EDIT: GPG Examples:
Verifying Bitcoin-Qt:
First download, import and check Gavin's key:
Download his key at bitcoin.org/gavinandresen.asc
In terminal or command line run:
gpg --import gavinandresen.asc gpg --fingerprint 
Check that the fingerprint for Gavin's key matches 01CD F462 7A3B 88AA E4A5 71C8 7588 242F BE38 D3A8.
Then download the wallet software and signature.
Verify the signature:
gpg --verify SHA256SUMS.asc 
You should see:
gpg: Good signature from "Gavin Andresen (CODE SIGNING KEY) " 
The signature for Bitcoin-Qt signs the hash values. So we must compute the hash of the downloaded software. This example is using the linux version.
gpg --print-md SHA256 bitcoin-0.8.6-linux.tar.gz 
Check that the output matches the associated hash value in SHA256SUMS.asc
Verifying Electrum:
First download, import and check ThomasV's key:
This key can be found at a keyserver.
gpg --keyserver pool.sks-keyservers.net --recv-keys 7F9470E6 gpg --fingerprint 
Check the fingerprint.
Download Electrum and the signature.
Verify the signature:
gpg --verify Electrum-1.9.6.zip.asc 
You should see:
gpg: Good signature from "ThomasV " 
For this example you do not need to compute any hash values because the signature is signing the downloaded file directly.
submitted by dcc4e to Bitcoin [link] [comments]

List of Bitcoin services that support increasing max block size

Repost: http://www.reddit.com/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/
Bitcoin companies and their services are an important layer of the Bitcoin ecosystem. They have a great understanding of Bitcoin technology, just like the devs, but their perspective is different. Let's see what they think.
Please inform me of any relevant opinions that I'm missing. I only want clear opinions, not borderline ones. Also, only opinions of companies clearly working with Bitcoin itself.
PRO
Coinbase & CEO Brian Armstrong https://twitter.com/coinbase/status/595741967759335426 https://twitter.com/brian_armstrong/status/595453245884997634
Blockchain.info Co-founder Nic Cary & CEO Peter Smith https://twitter.com/niccary/status/595707211994763264 https://twitter.com/OneMorePetestatus/595676380320407553
BitPay CEO Stephen Pair https://twitter.com/spaistatus/595341090317799424
Xapo CEO Wences Casares https://twitter.com/wences/status/595768917907402752
Third Key Solutions CTO Andreas Antonopoulos https://twitter.com/aantonop/status/595601619581964289
Armory CEO Alan Reiner http://sourceforge.net/p/bitcoin/mailman/message/34093337/
Bittiraha.fi & CEO Henry Brade https://twitter.com/Bittirahafi/status/596682373028311040 https://twitter.com/Technom4ge/status/596334370803326978
Kryptoradio creator Joel Lehtonen https://twitter.com/koodilehto/status/596675967667568641
AGAINST
MPEx http://qntra.net/2015/01/the-hard-fork-missile-crisis/
GreenAddress http://www.reddit.com/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84
submitted by Technom4ge to Bitcoin [link] [comments]

Rolling UTXO set hashes | Pieter Wuille | May 15 2017

Pieter Wuille on May 15 2017:
Hello all,
I would like to discuss a way of computing a UTXO set hash that is
very efficient to update, but does not support any compact proofs of
existence or non-existence.
Much has been written on the topic of various data structures and
derived hashes for the UTXO/TXO set before (including Alan Reiner's
trust-free lite nodes [1], Peter Todd's TXO MMR commitments [2] [3],
or Bram Cohen's TXO bitfield [4]). They all provide interesting extra
functionality or tradeoffs, but require invasive changes to the P2P
protocol or how wallets work, or force nodes to maintain their
database in a normative fashion. Instead, here I focus on an efficient
hash that supports nothing but comparing two UTXO sets. However, it is
not incompatible with any of those other approaches, so we can gain
some of the advantages of a UTXO hash without adopting something that
may be incompatible with future protocol enhancements.
  1. Incremental hashing
Computing a hash of the UTXO set is easy when it does not need
efficient updates, and when we can assume a fixed serialization with a
normative ordering for the data in it - just serialize the whole thing
and hash it. As different software or releases may use different
database models for the UTXO set, a solution that is order-independent
would seem preferable.
This brings us to the problem of computing a hash of unordered data.
Several approaches that accomplish this through incremental hashing
were suggested in [5], including XHASH, AdHash, and MuHash. XHASH
consists of first hashing all the set elements independently, and
XORing all those hashes together. This is insecure, as Gaussian
elimination can easily find a subset of random hashes that XOR to a
given value. AdHash/MuHash are similar, except addition/multiplication
modulo a large prime are used instead of XOR. Wagner [6] showed that
attacking XHASH or AdHash is an instance of a generalized birthday
problem (called the k-sum problem in his paper, with unrestricted k),
and gives a O(22*sqrt(n-1)) algorithm to attack it (for n-bit
hashes). As a result, AdHash with 256-bit hashes only has 31 bits of
security.
Thankfully, [6] also shows that the k-sum problem cannot be
efficiently solved in groups in which the discrete logarithm problem
is hard, as an efficient k-sum solver can be used to compute discrete
logarithms. As a result, MuHash modulo a sufficiently large safe prime
is provably secure under the DL assumption. Common guidelines on
security parameters [7] say that 3072-bit DL has about 128 bits of
security. A final 256-bit hash can be applied to the 3072-bit result
without loss of security to reduce the final size.
An alternative to multiplication modulo a prime is using an elliptic
curve group. Due to the ECDLP assumption, which the security of
Bitcoin signatures already relies on, this also results in security
against k-sum solving. This approach is used in the Elliptic Curve
Multiset Hash (ECMH) in [8]. For this to work, we must "hash onto a
curve point" in a way that results in points without known discrete
logarithm. The paper suggests using (controversial) binary elliptic
curves to make that operation efficient. If we only consider
secp256k1, one approach is just reading potential X coordinates from a
PRNG until one is found that has a corresponding Y coordinate
according to the curve equation. On average, 2 iterations are needed.
A constant time algorithm to hash onto the curve exists as well [9],
but it is only slightly faster and is much more complicated to
implement.
AdHash-like constructions with a sufficiently large intermediate hash
can be made secure against Wagner's algorithm, as suggested in [10].
4160-bit hashes would be needed for 128 bits of security. When
repetition is allowed, [8] gives a stronger attack against AdHash,
suggesting that as much as 400000 bits are needed. While repetition is
not directly an issue for our use case, it would be nice if
verification software would not be required to check for duplicated
entries.
  1. Efficient addition and deletion
Interestingly, both ECMH and MuHash not only support adding set
elements in any order but also deleting in any order. As a result, we
can simply maintain a running sum for the UTXO set as a whole, and
add/subtract when creating/spending an output in it. In the case of
MuHash it is slightly more complicated, as computing an inverse is
relatively expensive. This can be solved by representing the running
value as a fraction, and multiplying created elements into the
numerator and spent elements into the denominator. Only when the final
hash is desired, a single modular inverse and multiplication is needed
to combine the two.
As the update operations are also associative, H(a)+H(b)+H(c)+H(d) can
in fact be computed as (H(a)+H(b)) + (H(c)+H(d)). This implies that
all of this is perfectly parallellizable: each thread can process an
arbitrary subset of the update operations, allowing them to be
efficiently combined later.
  1. Comparison of approaches
Numbers below are based on preliminary benchmarks on a single thread
of a i7-6820HQ CPU running at 3.4GHz.
(1) (MuHash) Multiplying 3072-bit hashes mod 23072 - 1103717 (the
largest 3072-bit safe prime).
* Needs a fast modular multiplication/inverse implementation. * Using SHA512 + ChaCha20 for generating the hashes takes 1.2us per element. * Modular multiplication using GMP takes 1.5us per element (2.5us 
with a 60-line C+asm implementation).
* 768 bytes for maintaining a running sum (384 for numerator, 384 
for denominator)
* Very common security assumption. Even if the DL assumption would 
be broken (but no k-sum algorithm faster than Wagner's is found), this
still maintains 110 bits of security.
(2) (ECMH) Adding secp256k1 EC points
* Much more complicated than the previous approaches when 
implementing from scratch, but almost no extra complexity when ECDSA
secp256k1 signature validation is already implemented.
* Using SHA512 + libsecp256k1's point decompression for generating 
the points takes 11us per element on average.
* Addition/subtracting of N points takes 5.25us + 0.25us*N. * 64 bytes for a running sum. * Identical security assumption as Bitcoin's signatures. 
Using the numbers above, we find that:
24ms (2) 100ms
block takes (1) 3ms (2) 0.5ms
Note that while (2) has higher CPU usage than (1) in general, it has
lower latency when using precomputed per-transaction aggregates. Using
such aggregates is also more feasible as they're only 64 bytes rather
than 768. Because of simplicity, (1) has my preference.
Overall, these numbers are sufficiently low (note that they can be
parallellized) that it would be reasonable for full nodes and/or other
software to always maintain one of them, and effectively have a
rolling cryptographical checksum of the UTXO set at all times.
  1. Use cases
computation. This currently requires minutes of I/O and CPU, as it
serializes and hashes the entire UTXO set. A rolling set hash would
make this instant, making the whole RPC much more usable for sanity
checking.
blocks/UTXO sets.
the past few blocks (computed on the fly), a consistency check can be
done that recomputes it based on the database.
[1] https://bitcointalk.org/index.php?topic=88208.0
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013928.html
[5] https://cseweb.ucsd.edu/~mihipapers/inchash.pdf
[6] https://people.eecs.berkeley.edu/~daw/papers/genbday.html
[7] https://www.keylength.com/
[8] https://arxiv.org/pdf/1601.06502.pdf
[9] https://www.di.ens.f~fouque/pub/latincrypt12.pdf
[10] http://csrc.nist.gov/groups/ST/hash/sha-3/Aug2014/documents/gligoroski_paper_sha3_2014_workshop.pdf
Cheers,

Pieter
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Trying to verify bitcoin armory PGP signature for checksum, failing

I downloaded the signed checksum file from here: https://github.com/goatpig/BitcoinArmory/releases/download/v0.95.1/sha256sum.asc
I have already imported the public key into my keyring as seen below:
C:\>gpg --fingerprint 98832223 pub 409698832223 2012-02-28 Key fingerprint = 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 uid [ unknown] Alan C. Reiner (Offline Signing Key)  uid [ unknown] Alan C. Reiner (Armory Signing Key)  uid [ unknown] Alan C. Reiner (Armory Signing Key)  sub 4096DE6B2D74 2012-02-28 
When I try to verify the signed checksum file however I get this:
C:\>gpg --with-fingerprint sha256sum.asc gpg: Signature made 11/03/16 06:05:06 AUS Eastern Daylight Time using RSA key ID 4922589A gpg: Can't check signature: No public key 
Can anyone confirm if I'm doing something wrong or if the signature file has indeed been tempered or signed with an alternate public key that I don't know about?
submitted by h4kr to BitcoinBeginners [link] [comments]

GPG instructions and public key list for verifying Bitcoin clients.

I have noticed their is a growing problem of fake bitcoin clients, and I expect the frequency and elaboratness of these fake clients to increase.
Verifying the signatures for these clients will detect if you are receiving anything other than what the signer the of the software signed. The exception to this is if the attacker acquires the signer's private key, which should be a lot more difficult than tricking users to visit the wrong site or hacking servers. This can also be addressed by using multiple signatures per client.
An important part of this process is acquiring the public keys for the sofware signers in a secure manner.
To help with this I have included a signed list of fingerprints and where to acquire the public keys to act as another source to verify the keys used to sign bitcoin clients.
I have also included instructions for verifying the fingerprint list and bitcoin clients.
To deal with the issue that posts and comments on Reddit can be easily modified I suggest other users (especially well known ones) post a signature of the fingerprint list in a comment in this thread, or at least a hash of the fingerprint list (not as secure but still better than nothing).
List of Fingerprints:
+++ Bitcoin-Qt: Signer: Gavin Andresen (CODE SIGNING KEY) [email protected] Fingerprint: 2664 6D99 CBAE C9B8 1982 EF60 29D9 EE6B 1FC7 30C1 Key ID: 1FC730C1 Key Link: bitcoin.org/gavinandresen.asc
Electrum: Signer: ThomasV [email protected] Fingerprint: 6694 D8DE 7BE8 EE56 31BE D950 2BD5 824B 7F94 70E6 Key ID: 7F9470E6 Keyserver: pool.sks-keyservers.net Signer: Animazing [email protected] Fingerprint: 9914 864D FC33 499C 6CA2 BEEA 2245 3004 6955 06FD Key ID: 695506FD Keyserver: pool.sks-keyservers.net
Multibit: Signer: Jim Burton (multibit.org developer) [email protected] Fingerprint: 299C 423C 672F 47F4 756A 6BA4 C197 2AED 79F7 C572 Key ID: 79F7C572 Keyserver: pgp.mit.edu
Armory: Signer: Alan C. Reiner (Offline Signing Key) [email protected] Fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 Key ID: 98832223 Keyserver: pgp.mit.edu +++
My Key:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.12 (GNU/Linux) mQINBFLB9nUBEAC/klZvqQkWP/NUD0pT09PzhKh0xIQ0XM7MxqUZLa1OytF3iUCX /fNwQD5OnSFQoEg1O4bGzrrRb+PiuKCvH19dp7sFVj3q7Dhwfb6EvsX39xqzxCr6 2AQFQ3esz4nNodnQWa48t2ujihaf/vpTn6n7+jCl6a124r+U4wNGiNIEWxLLUNNb ec8S1RcjtTp6Ue/yRpThgJN9e4rj19+vJMqKCiqL03NBZWVoCEkL6iIdjwlQK8/r CpP9m5yAsc8wkelRkZvuLmjJ1GgSFrO0WteGnURMshy59LetaSRyiIDeHaPdV5rk /n3mBv8hsK/39O6H7fYWDx/ZLnZE4rMghcndexIFLhsuPx6FJNATqQ2gHT4ijb8K NlwZ0LatlXyUEMKfC1aroa3/9RkQSf0y0GKS0XrvUWGVRn/X7gk1DRhuaHWuacCf k3w0XZOA2WpWw1w/rjZSeHbKG1w4B2/kWH3K4sXsfcLltlY85zH03HUYSx+leMFc yxiHz60ZfuV2aGjYFPL8dzF6DS106lHz51j608OZkAEO8Xssincii1k/PR1h1y2P AqgrEADzgl52iBbNw+tdnxSAIy/asEyxU/VwkUFjOzSyP7ZmBxg8ss966w2Kl6WE o9R5tkVuUG8WTMTnF0FeMxO9YOqx4KhN9bhP7RjBL7BFTvRXYVVJUGabIQARAQAB tBVkY2M0ZSA8ZGNjNGVAZ214LmNvbT6JAj4EEwECACgFAlLB9nUCGwMFCQlmAYAG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJECO6L0dAOWOhsNIQAKUN9Z4e0hM3 DbaUjYJx93JGdJArLmz+Ko10N/lGcao4lCNVA+xM73Ga1GBnPlhPFW9iD2VQocOv tY2PYNsPrHgGlzyMKAMSpZ8364wVEyCHdJVKFORUjhyuJGYfyhDt2iZuzQwxWbmQ 1gmlbiGvxRysmaSW5+M8CDhja/fI8+EOp5NbH/EvHJClul3cO72UBUXBPxRv4Eb+ j8k0Uozob70A3bD894F8bJ9wZ3XBX/9DEkAbvDyW7CxIZwUiCeYTQylH++8S91A1 wL3z35ELdOLzGqwetYY6gSZRwY/W+rewEfPfBDSRjXKOBfhraMBYV1Sdg0IUj10W 2XVAzkqmqaej0T/xTt6aNjFtiH1u18BUpYIcCAAZ6TJ7325bnqnI+0xWFdonyggL +AIX1nzhx5niw8ZkCX0/jlJAx3TXAuxX/Tfy7cVSVi33v0fiwoDb8ZIDBzg0P2uc PUpR13B3AevFpxuAuAFPWfTDOJQmZyn9YNswVOhNb9rfq5bkmaSBlMRefTtUKIjW XjrRhSULPJ73H+R1DNL1Y0vhclnkOVCFRB+VPChkO+6RitGQDTg/Z60fBHpnYiDz sysnsoojLwBGanHO5mZMprxADc9CmeRGRmfHwvx7eJvW1HqN+5JR3Ai+JDlT+IxX RNUQxUbOry4D8TwRn9nBEtumNyNQcBmUuQINBFLB9nUBEACyRFYCrOXxC8yWm92U qPPNa3YC+W17O4rHW/thKTze1/TeZAKTNaIMPCS7iSVBBRbuijG+8NsgFd6W9acC ihMD4VUdFhVPjRGM3HmqzsxudVI4kGlQl8w86pYZu8ceGB4LQcoUFbPmWgXDIszH NV7kIFO/2oCRJ7VIBllUMP97RRdIfDND7EZMWvDveZ40BZCBLfnD9f6VSs4Lgn2C ow/ko01ijnvUxA/BGPJKI7JTLJHbdL//RQwT3AacLSc/etIurY2Ef926XbYYI1gi qboCU/dYUkGG2D+BDcGdukwpksdZZSXPyNhkZQAPPViHuFFtHI3C+FNb5L+lnC0h /dfF73U1lN3jp/VX11U1tIsHJyPjs8aael2UJO7Qy3vgVRM6KOywNNjVRv79Z/rF YHkNzBwXrGKdwV16SdRWjgkzkB4JeNQME096SqrwAEj/j5fwMqHjR8dKqWKDT6s9 V2Z83go3n9kI8JWFh33OksBh/qpKghhwtGWrUsbVcEDOVmUn2ozXvARDzqnNw3DN PcQvzUtasD8hxGHo7fW4TczdtgS3b/DfU2VJo68Fmo1C4eqYX+Ixx05khFCtP7d0 POqX6jIIQqZq8NTea8/M8Xx1YGhR5RpA4vZe7bCLgD2VUXHL43Npmq2nuZ0/7AwY H0hc/y/T+SU70xn28XyWHHLkCwARAQABiQIlBBgBAgAPBQJSwfZ1AhsMBQkJZgGA AAoJECO6L0dAOWOhIcgP/ioKYiJFAsolS4ep1PenCPvQFjvZTq4xJnsubEJ/ERU8 zdgET0Rh5jcCLqRAxQbGW3lVsewR3N+S9Rt3zHApqfZBFg5XJkZxsk0u+0qGPHWA 4oC7U3E4ZwMfVzUDcfKrzD1h0JaiSW1+1qgCh9/YVCUYakR1n/9LgzPP8ekQLTeb nWE+ZQQfeTDgoTNFWZvUlEbh4zcHLvcay78PnK3uT3UbWPyltSxon/eD47s1dt03 P/8nqaXCZhhRZ9N3EbJyudLBgA3ctySSJJSKKQHYynH5qUQqKp4Wq1KY80161xvW FqKwN/Jr4tTpRVZPu8P82cxhwrWJdf1U3/M2F2aIgXbGS4fHbzsLZ+6zZ3AuT4D8 auW55GOrnoF9XzZV6IavtluILUXMjVzF13slo5PKzS8yyJRNxE22krbeEyUum4Zu dDiERxIB6B+RDMM9qvV9svGJoEXG+4ugwkA3R7a6LWApmkvH3eXpULfDN2g5eNcr 5efFMrI/myxmpsP3nUp5EZFJyp8+ZSzIMJ1jSzXH8mHajIGTG49xDyZGpbog3wd2 7aQf5D9WOuKfYZM9MU9PBF+ZgtNrAxWuYJcCOr4WEd/2IjayMWvLxNA/RVW66oVj puaaDc3m3hXg1fwUWv9ZJyMUv7NARLgig3KEMVZiVzos7ZMn9mZNrOk2fnkKpVJB =ufyu -----END PGP PUBLIC KEY BLOCK----- 
Signature for fingerprint list:
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (GNU/Linux) owGFk31QFGUcx48XIU/KU0YSZOhHToraHeze3u4tqd2+HZ6g4ks6ZBTLsXdud7eH ewtCV4mp4/hGKmlTQbyEkgoZxpg6kReML0RWaoohOWWN0mhK4WSZje0Zxw0zzfTP 7rPf5zfP7/N8nn22PRyliYyYfDQ9y0La6yNaotYW6hyi5BTkYlmUFJ9BKVMWdZyu mDFjhpYWFbtXlPQLlUztYtEpCXImZPGlogSUVCQLPkGCNGYBy8FiW9Z82/wsyOby poEzWMEPFVicHl50G+xeD1jDXTIBxXEMcJYkgaEpDhiSNgNCmlHgrHgGoCRLAsfh NCBWhgBjBoNos4VysLGZD5LhIEeUXJlQ+C+nwSs700d0N/A+u5ZzC3ZFLvGE97Bk hdfD+5aC8uBdiqiQZYYiQTuCEMdJDFizujuC5swqjQkHI0JzwJImlZBmTWBGMRoI q1pHZHD4MGEwCQU+QS4Ntiz2et0Gn8und4Uyn0ESlGEkShI9/Etqf5jJh4Zhd7NH opEkgoEZx1iwMkYjYCTJAM5QKADNcRSgKGZSnWWogkmTCTJwKzvMFkxCwf+xzStx K6LqNixurugBukRWvOrBe4Zmg9ahSCgV3N5iQZ4GL4oeHDFbHLxPGcI3lLhG8qNB YAw1qtQEagWMsKoGTTgFOE1hwCAkASjFsUCQVgIYE4GG1apJKBjGdxYbPCqHUFSi pWSPVy4PA1NuXgLGAIsEUf2GtAUOh1sdQXA+KFtdZhrwapFl6B/iHywQdD4S2Ywi VkBQlAQjTrPAmnBVMa4iM0b1gVE0AjiluifNZqN6AKhxGDmYhIL/Qg5etI2RydGa iEhNzKjI4N3TaEfrQjf0brJOs692U9vbzb2jMs51uP1Jl/6KXf7NoTEHolxXvvRf SjzbEylrjFvH1jXefbJxd9/tK8u8SVdLC9yv5N88N/v1Cyu7N1deXDPJMeVs8obj b9zvtW84sv9OWeJJ8tXyPX2/N+zqGn+ZnxCdGz++QXqzYGzthSRE7JJaflRu4/01 jqsFuat62ifvHujc8ZhupW1P59OBjoMtgz+crx08mdN/sDkwtUmfLecN2Hb8duuz Lxq6Aztjz3RsWV1d3TJBc4D86cbfuqjvn0iJemqvfk1/ToHQFZhtWrT555eZwh45 +vNj/jX7Fubnd/3adNxf+EhF7sWmMX+Q184dSvygFdFXBF6b2m1KjLvnoKanzEp0 2cWqgX7L2biU8/2xt5LudZ4g4pawCZVpv6T7q1JfaN9Q1xFxP2Z55fiPuo7tvXdd v6m3vrLt+Tk12bGzDn/rr8+puxl4vLsqrnPKmPg51xUZo+tiXKuf2XZ44DLd8t7N weL21tONnY2jKy+MSzi1/1o8sWrQPPPTd1tteW/tTct6fyO2NNWUJ6wT6mPWx9fz 31ml53QTe75a+2HbumVuvZCcC33V0/fFpM07wkRYUh9a0LxzK6mrOuqYChWT6u4M oGkJS2vmNkWdmdWcP5le4ulLbr+Ws+IysX37OyfSt4y70St8vLov9dE/k3Y1zNy4 SyrY/fWzvRMLP8mNrjh1eFvtznXt/wA= =5zDz -----END PGP MESSAGE----- 
Hashes for fingerprint list:
SHA-256: 7A6B9841 355B1127 E5639A9D 7040D81C F395D382 884376C2 31829C63 6FCF1B80
SHA-512: 04A49A60 A1645479 ED0B3CE9 AE32E156 E9768CC2 0D4EF393 814162BE BFA6FAF5 6C520769 C654467F 6B61EBD4 4A5A5C93 9DF81B7D AA468A50 2DD7FFF3 F637A49C
Verifying the fingerprint list:
Save fingerprint list, from the first plus to the last plus, to a text file called fingerprints.txt
Next save my key to a file called dcc4e.asc and my signature to a file called fingerprints.txt.asc
In terminal or command line run:
gpg --import dcc4e.asc gpg --verify fingerprints.txt.asc 
You should see:
Good signature from "dcc4e " 
GPG examples for verifying Bitcoin clients:
Verifying Bitcoin-Qt:
First download, import and check Gavin's key:
Download his key at bitcoin.org/gavinandresen.asc
In terminal or command line run:
gpg --import gavinandresen.asc gpg --fingerprint 
Check that the fingerprint for Gavin's key matches 01CD F462 7A3B 88AA E4A5 71C8 7588 242F BE38 D3A8.
Then download the wallet software and signature.
Verify the signature:
gpg --verify SHA256SUMS.asc 
You should see:
gpg: Good signature from "Gavin Andresen (CODE SIGNING KEY) " 
The signature for Bitcoin-Qt signs the hash values. So we must compute the hash of the specific downloaded software manually. This example is using the linux version.
gpg --print-md SHA256 bitcoin-0.8.6-linux.tar.gz 
Check that the output matches the associated hash value in SHA256SUMS.asc
Verifying Electrum:
First download, import and check ThomasV's key:
This key can be found at a keyserver.
gpg --keyserver pool.sks-keyservers.net --recv-keys 7F9470E6 gpg --fingerprint 
Check the fingerprint.
Download Electrum and the signature.
Verify the signature:
gpg --verify Electrum-1.9.6.zip.asc 
You should see:
gpg: Good signature from "ThomasV " 
For this example you do not need to manually compute any hash values because the signature is signing the downloaded file directly instead of signing a list of hashes.
submitted by dcc4e to Bitcoin [link] [comments]

List of Bitcoin services that support/oppose increasing max block size

(Copy of https://www.reddit.com/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/)
Please help updating
PRO
Coinbase & CEO Brian Armstrong https://twitter.com/coinbase/status/595741967759335426 https://twitter.com/brian_armstrong/status/595453245884997634
Blockchain.info Co-founder Nic Cary & CEO Peter Smith https://twitter.com/niccary/status/595707211994763264 https://twitter.com/OneMorePetestatus/595676380320407553
BitPay CEO Stephen Pair https://twitter.com/spaistatus/595341090317799424
Xapo CEO Wences Casares https://twitter.com/wences/status/595768917907402752
Third Key Solutions CTO Andreas Antonopoulos https://twitter.com/aantonop/status/595601619581964289
Armory CEO Alan Reiner http://sourceforge.net/p/bitcoin/mailman/message/34093337/
Bittiraha.fi & CEO Henry Brade https://twitter.com/Bittirahafi/status/596682373028311040 https://twitter.com/Technom4ge/status/596334370803326978
Kryptoradio creator Joel Lehtonen https://twitter.com/koodilehto/status/596675967667568641
BX.in.th https://twitter.com/BitcoinThai/status/605022509101023232
Jameson Lopp, BitGo engineer https://twitter.com/lopp/status/605041173439209472
Breadwallet CEO Aaron Voisine http://sourceforge.net/p/bitcoin/mailman/message/34096857/
OKCoin https://twitter.com/okcoinbtc/status/598412795240009728
BTC Guild founder, Eleuthria https://www.reddit.com/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3
Coinwallet.eu http://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981
AGAINST
MPEx http://qntra.net/2015/01/the-hard-fork-missile-crisis/
GreenAddress http://www.reddit.com/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84
Bitcoinpaygate http://www.reddit.com/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp
Bitrated founder Nadav Ivgi https://twitter.com/shesek/status/605005384026177537
David Francois, CTO of Paymium http://fr.anco.is/2015/gavineries/
submitted by usrn to bitcoin_uncensored [link] [comments]

[Informational] [CC0] Maslow's Hierarchy of Coins

Hierarchical Deterministic Wallets

Bitcoin Wallets generate and store the private keys that control a user's funds. These keys are simply random numbers, chosen by the wallet from a range of numbers so vast that it is essentially impossible for there to be a collision with another wallet doing the same thing. Deterministic wallets, also known as HD wallets help to simplify backing up and restoring wallets by using a random seed number to deterministically generate all of a wallet's private keys.

Private Key Backups

Whenever a Bitcoin user receives funds, they need a new private key. This means that the set of numbers that are important to store and back up is increasing indefinitely. In the original Bitcoin wallet, this required refreshing a back-up with a new one every time a user received funds.
Over time, Bitcoin grew more valuable and this burden of security grew more tiresome and costly. To address the issue Satoshi Nakamoto in October of 2010 released Bitcoin version 0.3.14 which contained a key pool feature. This feature automatically pre-generated a set of keys, to remain in abeyance for the user's next receipt of funds. This made backing up a much less frequent necessity, only being necessary after key pool exhaustion.
Over the following years, many other methods of improving key backups were tried. A popular concept of a paper wallet arose: printing a private key onto paper to store in a secure location. However this concept fell out of favor as being too complicated, vulnerable to printer information leaks, and encouraging address re-use.

Type 1 Deterministic Wallets

In August of 2011 Mike Caldwell sought to simplify and streamline the process of managing a collection of private keys. He created a Windows application called Bitcoin Address Utility that used a single random pass-phrase to deterministically create private keys from a single seed: essentially choosing one random number and then feeding it into a formula that would always produce more random numbers from the starting one.
This created a much easier way to backup private keys: simply secure the original random seed and restoring becomes a simple exercise of running the seed through the algorithm again.

Type 2 Deterministic Wallets

Mike Caldwell's Type 1 deterministic wallet design was based on a simple scheme that had a significant limitation: to receive funds with a Type 1 wallet required also having access to the private keys that could spend them. In situations such as merchant scripts or exchange wallets, this represented a security issue.
Before Mike Caldwell published his Type 1 wallet, in June of 2011 Greg Maxwell had already outlined a theoretical improvement to the Type 1 scheme, in which the public and private key generation might be separated to improve the security of stored funds. In Greg's outlined Type 2 scheme, a script could use what is called a master public key to generate new addresses, without ever being able to spend those funds.
In February of 2012, Pieter Wuille came up with a formalization and standardized version of this concept, in BIP 32. A surge of wallet development activity followed the deterministic wallet concept. Since the master seed behind the wallet may be represented as a simple series of twelve words, it was widely considered to be the superior method for Bitcoin wallet private key generation.
Alan Reiner was the first to implement a Type 2 seed in Armory Wallet, and helped give feedback to the BIP 32 formalization. Since then, every major wallet has moved to support the feature.

BIP 44 Deterministic Wallets

After BIP 32, development of Type 2 deterministic wallets progressed to a state where additional features and standardization was sought to be defined. In April of 2014 Marek Palatinus, also known as Slush, and Pavol Rusnak, Slush's employee at his company SatoshiLabs, sought to advance the state of deterministic wallets by adapting advancements in their own Type 2 hardware wallet Trezor into a standard they authored in BIP 44.
Features promoted by the BIP 44 standard included a mechanism for internal pass-phrase protected accounts inside of a wallet seed, a standard for using the wallet seed across multiple chains, such as for Bitcoin Testnet, and an increased standardization of gap limits and change address separation.

Deterministic Wallet Caveats

Despite the huge improvement in the state of Bitcoin technology that HD wallets represent, there are some outstanding issues and drawbacks or gotchas that may present difficulties.
Deterministic wallets generally present users with a dictionary derived random pass-phrase that actually represents a master seed number in a form that is easier for humans to deal with. But this ease-of-use has sometimes tempted developers into allowing users to set their own pass-phrase, a very bad idea. Users are extremely bad at choosing a properly random pass-phrase, and this behavior can lead to loss of funds. For this reason, all well-maintained wallets have ceased the practice of encouraging users to invent their own pass-phrases.
Another issue that sometimes confronts users in unexpected ways is that the seeds created by deterministic wallets should not be shared between wallets from different software projects. The reason for this is that the standard for deterministic wallets is generally not actually adopted by all wallets, or there are still areas left unspecified. Due to these small differences, seeds may superficially appear to be share-able between wallets, but in actuality leave some coins difficult to access from the non-originating wallet. To switch between deterministic wallets, the best practice recommendation is to initiate fund transfers on the Blockchain.
From a security and privacy perspective, under normal circumstances a deterministic wallet is just as good as a wallet in which random keys are individually generated. However use of the public master key can prove the exception to that rule. Although it is called a public master key, for privacy reasons it should not be shared publicly, as it can link all wallet addresses together. Another important reason it should not be shared is that if a single private key derived from the private seed is leaked and the public master key is also known, all the other private keys may be derived as well. This type of theft is quite uncommon, but for these reasons it is strongly recommended that the master public key still be treated as guarded information.
One practice that must differ between using an individually generated wallet and a deterministic wallet is the practice of creating addresses that are never used. HD wallets have a key implementation detail in the way that they calculate wallet balances: they go through their deterministic algorithm sequentially to determine if each private key has been used, stopping when no further activity is detected. This is a critical optimization, an HD wallet cannot scan endlessly or know automatically all of its balance information without individual queries. To provide a safety margin, HD wallets use something called a gap limit, which represents the number of keys checked that have no activity before the balance query will cease its sequential checking. This gap limit can means that creating many addresses that are never used is a bad practice and can lead to users mistakenly believing their funds have been lost, if more unused addresses are created beyond the gap limit safety margin.
A powerful feature of BIP 44 HD wallets is the internal pass phrase account system. This feature addresses a common security concern amongst people who worry about keeping their seed backups secure from theft: it adds an internal password to the stored seed. The feature also powers another use-case, a scenario in which the owner is confronted with the seed and forced to give access to it. As a precautionary measure, the owner may create a red-herring pass phrase and a real pass-phrase, pretending that the red-herring phrase contains the entirety of the funds when forced to open the wallet under duress. But with this power also comes risk deriving from any situation where users choose pass phrases to remember. Human generated pass phrases should generally be considered weak: a brute-force attack can most often bypass them. And memorized pass phrases can be easily forgotten, leading to an annoying situation where funds are temporarily inaccessible, or if a truly strong pass-phrase has been chosen, permanently lost.
submitted by pb1x to writingforbitcoin [link] [comments]

Why Bitcoin is and isn't like the Internet | 21E14 | Jan 21 2015

21E14 on Jan 21 2015:
This is a response to a wonderfully insightful recent post by Joichi Ito,
the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board
Member of ICANN, offered his thoughts on "Why Bitcoin is and isn't like the
Internet" and asked a most pertinent question: "Whether there is an ICANN
equivalent needed for Bitcoin." As suggested in recent posts to the mailing
list, I believe there might be, but for a reason that may not seem obvious
at first.
Alan Reiner expressed the need this way: "I think one of the biggest issues
facing Bitcoin right now is not the lack of a 'killer app.' It is lack of
insurance options. Early adopters would like to believe that the majority
of users will hold their own Bitcoin, but I believe that is not a realistic
option when life-changing quantities of Bitcoin are involved. We should not
trust Grandma to secure her own retirement savings via complicated computer
maneuvers. More to the point, she should not trust herself or anyone else
(sic!) to hold it unless there is a strong protection against loss events.
Right now the solution is for Grandma to avoid keeping her money in
Bitcoin. Bitcoin needs a strong backbone of insured storage options so that
Grandma can confidently participate in this new technology." This is
certainly an observation to take heed of coming from the founder of Armory
Technologies.
The protection against loss events ought to be understood in the broadest
sense. What is needed is a disaster recovery mechanism. Andreas
Antonopoulos remarks expressed this candidly last year: "Bitcoin doesn't
have a middle of the road mediocre growth model. It basically either dies,
because of a fundamental flaw in the Bitcoin system. Not an external
factor, an internal factor: We blow it up by accident. And that could
happen... Bitcoin will play out in the next three years. In the next three
years we're going to see Bitcoin arrive on the global stage and make a
substantial impact, both in financial terms and in political terms. It will
happen. Or it will die. Either way. I'm not sure. In which case we'll
reboot another currency."
A body, not entirely unlike ICANN, can manage the nexus to the physical
world, and help address Bitcoin's catastrophic failure modes. Bitcoin's
coin ownership protocol would thus join the ranks of its payment protocol,
coin issuance protocol, consensus mechanism and inflation control that pose
no lethal threat to the ecosystem. In addition to their coin-agnostic
nature, I suspect the high valuation of large Bitcoin hubs relative to
Bitcoin's market cap at this stage in its lifecycle is partly reflective of
the sneaking suspicion that a custodial bitcoin (a bitcoin attached to an
identity) may be worth more than a non-custodial one. With this in mind,
I'll pitch in for the ticket should Dr. Ito decide to join the next month's
DevCore Boston conference aimed at supporting the future development of
Bitcoin. It's an hour's walk from MIT after all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150121/45fa2d7d/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007158.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Lista de serviços de Bitcoin (empresas e pessoas) que estão a Favor & Contra aumento do BLOCK SIZE

A favor
Contra
submitted by brasilbitcoin to BrasilBitcoin [link] [comments]

Bitcoin estimula criação de startups de proteção

Portland - Após aumentarem em 90 vezes seu valor no ano passado, os Bitcoins se tornaram um alvo atraente para hackers e ladrões, gerando uma oferta cada vez maior de startups criadas para proteger o dinheiro virtual dos investidores contra perdas.
Desde a criação da moeda, ocorreram mais de 35 grandes fraudes e furtos de Bitcoins no mundo, incluindo o roubo de 38.527 Bitcoins da casa de câmbio on-line Bitcoinica LLC, em maio de 2012, segundo o site BitcoinTalk.org.
Cerca de uma dúzia de startups, de uma empresa que fabrica moedas chamada Titan Mint Inc. a um mercado chamado BitShares que permite que as pessoas troquem Bitcoins entre si, busca amenizar as preocupações a respeito da vulnerabilidade do Bitcoin. Estas empresas oferecem de tudo, desde moedas de metal estampadas com códigos de segurança até contas on-line criptografadas.
“O risco existe e é suficiente para afastar alguns usuários”, disse Nicholas Colas, estrategista-chefe de mercado do grupo ConvergEx em Nova York. Ele estima que mais Bitcoins são perdidos para bandidos e hackers hoje do que dólares para ladrões de banco.
Uma vez que os Bitcoins são armazenados como arquivos de software em “carteiras” ou pastas em sites, computadores pessoais ou smartphones, isso deixa seus donos suscetíveis a perdas para ladrões, falhas ou hackers. E devido ao fato de que o dinheiro digital foi desenvolvido para ser difícil de rastrear, qualquer saque é semelhante a um saque em dinheiro e é mais difícil de monitorar que o dinheiro real guardado em contas bancárias.
O valor exorbitante dos Bitcoins, que aumentou de US$ 12 no início de 2013 para mais de US$ 1.000 em novembro, transformou-os em um alvo mais tentador, de modo que os esforços extras de proteção compensam.
Dinheiro real
De um total de um milhão de pessoas com carteiras de Bitcoin, alguns milhares perderam seus fundos, segundo Andreas Antonopoulos, um analista de segurança de Bitcoins.
O alcance dos roubos é difícil de medir, porque os Bitcoins são feitos para serem uma moeda autônoma difícil de rastrear.
Criado em 2008 por um programador ou grupo de programadores desconhecido, o Bitcoin tem seu fornecimento regulado pelo software básico da moeda e só pode ser feito através da solução de enigmas complexos incorporados ao código do Bitcoin. O dinheiro digital está sendo usado para comprar de tudo, desde chocolates até câmeras digitais na internet.
Michail Wilson, administrador de sistemas de 42 anos de idade em Seattle, transformou suas reservas em moedas físicas da Titan Mint. Cada moeda -- que pode ser disponibilizada em ouro ou prata -- contém um código de resgate para desbloquear os Bitcoins.
“Eu gosto da ideia de poder ter algo nas mãos”, disse Wilson, que contou que comprou 230 moedas da Titan e depois vendeu metade delas para outra pessoa. “Eu não tenho que me preocupar se serei hackeado. Eu posso simplesmente jogá-las em um cofre e não me preocupar mais se minha carteira será hackeada”.
Alguns desenvolvedores de novas tecnologias de segurança do Bitcoin têm formação em criptografia e segurança militar. Alan Reiner -- CEO da Armory Technologies Inc., a produtora da Bitcoin Armory, carteira segura de Bitcoin que foi baixada 65.000 vezes nos últimos seis meses -- trabalhava com defesa antimísseis no Laboratório de Física Aplicada da Universidade Johns Hopkins.
Oportunidades de segurança
Ian Purton, desenvolvedor do StrongCoin.com, aprendeu sobre o Bitcoin enquanto desenvolvia softwares para bancos de investimentos. Dan Larimer, que está construindo uma casa de câmbio mais segura para a moeda, trabalhou com veículos robóticos.
“Nós temos problemas de segurança, mas também temos oportunidades de segurança”, disse Antonopoulos, o analista de segurança, em uma entrevista. “Nós podemos inovar em relação ao dinheiro”.
No caso das moedas da Titan, cada uma delas é registrada com um endereço de e-mail e uma senha, que são necessárias para resgatar o valor em Bitcoins armazenado com elas. Para usar as moedas, os usuários descascam um holograma de segurança para desvendar um código único de resgate. Tim Fillmore, presidente da Titan, disse que a empresa vendeu mais de 1.000 moedas desde que elas foram colocadas à venda, em setembro.
“Elas são realmente pensadas para atrair os colecionadores de moedas e compradores tradicionais de ouro”, disse Fillmore.
EXAME
submitted by allex2501 to BrasilBitcoin [link] [comments]

Receiving Bitcoin - Armory Guide Bitcoin Armory - Simulfunding a Lockbox Bitcoin Armory - Creating a Lockbox OlgaShow interview of Alan Reiner, Armory BitCoin Client. Alan Reiner - Lead Developer of Armory Wallet

Alan Reiner. I started as a miner, without much knowledge of what Bitcoin was or its potential for disruption. All I knew was that I could get a decent return on my investment if I mined bitcoins and sold them on Mt. Gox. After some time and many media reports of Bitcoin thefts, I decided I wanted better security for my own funds. The community ... Alan Reiner war der ehemalige CTO und Gründer von Armory. Er ist ein Pionier der Kryptowährungssicherheit und weithin anerkannt als ein weltweit führender Bitcoin-Sicherheitsexperte und als eine vertrauenswürdige Quelle für Best Practices im Bereich Sicherheit. Unter seiner Führung hat Armoury neue Bitcoin-Sicherheitsfunktionen und Unternehmensfunktionen eingeführt. Alan Reiner was the former CTO and Founder of Armory. He is a cryptocurrency security pioneer and widely recognized as a world leading Bitcoin security expert and as a trusted source for security best practices. Under his leadership Armory innovated new Bitcoin security features and enterprise-grade functionality. limit my search to r/Bitcoin. use the following search parameters to narrow your results: subreddit:subreddit find submissions in "subreddit" author:username find submissions by "username" site:example.com find submissions from "example.com" url:text search for "text" in url selftext:text search for "text" in self post contents self:yes (or self:no) include (or exclude) self posts nsfw:yes (or ... Einige Bitcoin-Enthusiasten bezeichnen Kryptowährung als "digitales Gold." Damit liegen sie jedoch falsch. Während Bitcoin sicherlich an Nutzen und Wert besitzt, ist es nur ein digitales Asset o

[index] [33558] [43316] [43698] [22497] [42269] [4274] [47405] [17331] [36784] [42817]

Receiving Bitcoin - Armory Guide

Alan Reiner from Bitcoin Armory discussing mulit-sig Lock boxes - Duration: 3:09. Contrarian Dude 1,104 views. 3:09. How to increase your value as a person-Jim Rohn - Duration: 41:09. ... Bitcoin Armory - Simulfunding a Lockbox OlgaShow interview of Alan Reiner, Armory BitCoin Client. Olga Media. Loading... Unsubscribe from Olga Media? ... Bitcoin - Trace Mayer at Inside Bitcoins 2013 Las Vegas - Duration: 21:06. THE ... "The US is bankrupt...and it's only going to get worse from here!" - Jeff Berwick Interview - Duration: 13:10. Cambridge House International Inc. Recommended for you Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

#