Bitcoin Forum
May 25, 2024, 03:59:13 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 [112] 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 ... 590 »
2221  Bitcoin / Development & Technical Discussion / Re: libsecp256k1 as a library/dll/etc on: September 23, 2017, 04:27:24 PM
Is it possible to use a dll for windows or library (.a) file to add it
to current project without installing dependances and compiling sources?
Sure, but AFAIK, no one publishes builds for it.

You can use mingw or cygwin to compile it and get the .dll/.a files for it.
2222  Bitcoin / Armory / Re: Armory+Core+Win10 - How I made it work on: September 23, 2017, 03:03:18 AM
- One of the big issues I seemed to have was having Bitcoin Core GUI open and trying to use Armory at the same time. The Bitcoin Core GUI seems to interfere with Armory's ability to connect with bitcoind... I highly recommend not having Armory and the Bitcoin Core GUI open at the same time.
If you enable manual mode that shouldn't be a problem. Manual mode is done by unchecking "Let Armory run Bitcoin Core in the background". This means that you will need to run Bitcoin Core yourself every time you want to run Armory and Bitcoin Core must be running before Armory starts.

- I didn't make any changes to Windows settings for this to work... it was basically, the "addnode" and "server" entry in bitcoin.conf and letting Armory run bitcoind that seemed to make it work for me
The addnode doesn't matter. It does not do anything that makes this different at all because Armory is not a node that accepts incoming connections nor is it bound to the default incoming connection port because Bitcoin Core is.

server matters as that is what starts the RPC server if you are using the GUI and not bitcoind.
2223  Bitcoin / Development & Technical Discussion / Re: How to push your own TX with a local node. on: September 22, 2017, 10:32:19 PM
Yes. If your node is Bitcoin Core (or is based on it), you can open the debug console (Help > Debug Window > Console) and use the sendrawtransaction command.
2224  Bitcoin / Development & Technical Discussion / Re: Hashing coinbase transaction to get txid on: September 22, 2017, 07:05:49 PM
Ok, great. But my regtest setup (version 14.1) gives me a similar raw coinbase transaction:
Code:
020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff050282060101ffffffff020e642500000000002321031a70a95a57f63b7d63e46803d385fd483b77f7a71a7a753ffcf7aafb67ec3edcac0000000000000000266a24aa21a9edad9d9c439414e2d257fda34cdc00667c0ecd7d78256721a4178046b49ee7382f0120000000000000000000000000000000000000000000000000000000000000000000000000
Is the implementation error in the node? Maybe working in 15.0?
Hmm. That's interesting. I can reproduce that. I will investigate and see what's up with that.

Regardless, the txid is calculated from the non-witness serialization of a transaction, so you should strip out the witness parts of this and hash the remaining. That will get you the txid.



Ok, so apparently that is actually expected behavior. From BIP 141:
Quote
and the coinbase's input's witness must consist of a single 32-byte array for the witness reserved value.
This is done to allow for future extensibility.
2225  Bitcoin / Armory / Re: Armory 0.96.3 released on: September 22, 2017, 07:03:19 PM
Also, goatpig didn't explicitly mention this but I believe this will fix the issues people were seeing when they ran Core 0.15.0.1 (i.e., the ones where goatpig told them to go back to 0.15). If you're still having issues, post your logs!
Yes, it does fix that problem, hence that one line under "== Fixed =="
2226  Bitcoin / Development & Technical Discussion / Re: Hashing coinbase transaction to get txid on: September 22, 2017, 04:56:19 PM
You seem to be working with the following:
Code:
01000000 00010100 00000000 00000000
00000000 00000000 00000000 00000000
00000000 000000ff ffffff31 03816b07
244d696e 65642062 7920416e 74506f6f
6c6b2f45 42312f41 44362f4e 59412f33
2059c36d 7be15500 00df3200 00ffffff
ff023825 2e4d0000 00001976 a9146603
71326d3a 2e064c27 8b20107a 65dad847
e8a988ac 00000000 00000000 266a24aa
21a9edc1 1e8cdbd8 d442b27b f8f27339
5baa83b5 da4c9c3d 87fbc539 dad74248
04371001 20000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00

Notice the extra "0120" at the end followed by an extra 36 bytes of "00"?
Also notice that you have an extra byte of "00" between the 4-byte version (the 01000000) at the beginning, and the "01" representing the number of inputs?
Then notice that you have an extra "01" byte immediately following the in-counter?
These extra bytes are resulting in an invalid hash calculation.
But I tried getting the raw transaction from electrum wallet and chainquery.com, and they all have the long tail starting with 12...
They seem to be giving you the transaction in the extended serialiation format (witness serialization when there are witnesses). This is actually incorrect and in violation of the segwit specification which states that the witness serialization for a non-witness transaction (as the coinbase transaction is) is the legacy non-extended (no witnesses) serialization format.

The extra 0001 between the version number and number of inputs is the marker and flag bytes for extended serialization. The 012000... at the end of the transaction is an incorrect and invalid witness (it means that there is a witness of 1 stack item which is 32 bytes in length and all 0's. During verification, this would be pushed to the stack, but it is incorrect to have that there at all).

Edit: That was wrong, explained in a post below.
2227  Alternate cryptocurrencies / Altcoin Discussion / Re: How does first wallet sync happen? on: September 22, 2017, 04:48:36 PM
if i have a wallet running with updated version and if it is the only wallet with updated protocol versions, how does it generate new blocks.
In whatever way the consensus rules specify that blocks should be generated.

Block generation has nothing to do with syncing.
2228  Bitcoin / Bitcoin Technical Support / Re: Have I lost my bitcoins? on: September 22, 2017, 03:33:05 PM
Due to the amount of nonsense, off topic, and spam posts, this thread is being locked.

OP, if you wish to continue any discussions in this thread, please let me know and I will unlock the thread.
2229  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.0.1 Released on: September 22, 2017, 03:24:04 PM
Ah, sorry, was working from (apparently very bad) memory.

So to answer Omega's question, presumably Bech32 addresses will in fact be more difficult to create vanity addresses with?
No, it will about the same difficulty. The bitness for what people will be using as vanity addresses (P2WPKH) is the same. It's still a 160-bit hash that you need to grind in order to generate a vanity address.
2230  Bitcoin / Development & Technical Discussion / Re: Lightning Network where are the transaction records stored? on: September 22, 2017, 03:16:09 AM
but how would you prove impartially your books are the correct record, when the other parties books say different?
The "books" would be the commitment transactions and their corresponding revoke_and_ack messages. The commitment transactions are signed by both parties, so you can prove that the balance for each transaction was agreed upon by both parties. The "books" cannot add transactions, only omit them. To prove that no transactions presented were omitted, you can use the per-commitment secrets and next per-commitment points in the revoke_and_ack messages to show which message corresponds to which transaction. If there is a revoke_and_ack message that has a next per-commitment point that is not used in any of the commitment transactions, then you know that at least one transaction was omitted.
2231  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.0.1 Released on: September 21, 2017, 09:29:38 PM
Few post up
Oh, I missed that.

He's wrong.

I think it would, not 100% sure, there may be some mathematical subtleties I'm not aware of. In principle, it should (I think this new Bech32 format is 32-bit in length and using base 36 numbers, whereas the current address format is 33 bit and uses base 58 numbers).
No, that is completely and absolutely wrong.

First of all, current addresses are 160 bits in length (bitness is not the same as character length). Bech32 addresses are either 160 bits or 256 bits. Bech32 uses base 32 and it will actually be longer than current addresses.
2232  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.0.1 Released on: September 21, 2017, 07:25:38 PM
Not sure going backwards is the way to go with bitcoin, ie the shorting of address length.. Seeing they want to use a different address for every single transaction. I mean people thought 4 billion ip (which also is 32 bit) addresses would be enough...
What are you talking about? The address length is not becoming shorter.
2233  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.14.2 Released on: September 20, 2017, 08:39:31 PM
Bitcoin Core 0.15.0.1 has been released: https://bitcointalk.org/index.php?topic=2191238.0

For technical support for Bitcoin Core 0.14.2 (or any other version of Bitcoin Core), please make a thread in the technical support section: https://bitcointalk.org/index.php?board=4.0
2234  Bitcoin / Armory / Re: Armory 0.96.2 is out (SegWit enabled) on: September 20, 2017, 08:24:45 PM
Downgrade until I put out the fix. ArmoryDB chokes on Core 0.15.0.1
By downgrade you mean downgrade Bitcoin Core, not Armory. Older versions of Armory will still have this problem. If you are not using Bitcoin Core's GUI, then the bug fix in 0.15.0.1 will not have any effect and downgrading is safe.
2235  Bitcoin / Development & Technical Discussion / Re: Trying to understand P2PKH mechanism almost there but not quite there. on: September 20, 2017, 01:57:42 PM
so I should believe this guy just because has been here and knowledgeable?
he virtually basically negated to major source of bitcoin technical materials and thinks he is right, lol and I should somehow discard what is written there and follow this guy at the same time being critisized??? Haha, WHAT A BIT-COIN-CIDENCE Grin Grin   Grin

https://en.bitcoin.it/wiki/Transaction
...
A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key...
You are horribly misunderstanding the page. The scriptPubKey is the output script of the output being spent. The scriptSig is the script of the input that spends the previous output. From the wiki:
Quote
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

The only time a script like
Code:
<CAFE SIGNATURE> <CAFE PUBLIC KEY> OP_DUP OP_HASH160 <CAFE PUB KEY HASH> OP_EQUAL OP_CHECKSIG
is ever seen is during script validation where the output script is concatenated to the input script (note that this is not how script validation is done anymore by the same idea remains). This only occurs during validation and is never present in any transactions. This is also explained on https://bitcoin.org/en/developer-guide#p2pkh-script-validation, particularly in the diagrams provided there.



Side note: please stop with the aggressive behavior, insulting those who are trying to help you, and shouting (typing in all caps). Otherwise you will be temporarily banned for flaming and I will lock and delete this thread.
2236  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15.01 on: September 19, 2017, 09:15:46 PM
What do you see about it that is not signed? Only the installers are signed and nothing changed in the release process that makes them not signed.
2237  Bitcoin / Development & Technical Discussion / Re: If Core had to hard fork and use another mining algorithm, what would it be? on: September 19, 2017, 09:10:05 PM
Could have sworn the argument used to be that it wouldn't be a valid hardfork unless there was a super-majority.  Now that it might happen, a super-majority is a bad thing because it suits you? 
No, the argument is still that a valid hardfork requires a super majority of all users of Bitcoin (meaning miners, businesses, and users), in fact, it requires consensus. A super majority of miners is not enough; miners do not and cannot dictate what Bitcoin is. You need a super majority of everyone involved in Bitcoin.
2238  Bitcoin / Development & Technical Discussion / Re: How do exchanges implement cold wallets and instant payments simultaneously? on: September 19, 2017, 09:07:02 PM
Most exchanges have a Hot wallet and a Cold wallet so not all coins are kept in Cold storage nor are they all kept online. The Hot wallet is online and that is the one that actually sends you the coins. IIRC you also usually deposit into the Hot wallet. Exchanges also have a Cold wallet where the bulk of their coins are stored. Coins are transferred from the Hot wallet to the Cold wallet when the Hot wallet becomes too full, and transferred from the Cold wallet to the Hot wallet when the Hot wallet becomes too empty. Such transfers are usually done on a regular basis.
2239  Bitcoin / Development & Technical Discussion / Re: how bitcoin transactions work under the hood: a visual guide in json on: September 19, 2017, 09:04:33 PM
This part is completely wrong:
Quote
What is signed by the signature in the spending transaction?
- snip -
It is neither the current or previous transaction, but rather a hybrid of both.  It includes the scriptPubKey from the previous transaction, which gave them ownership in the first place and

The scriptPubKey of the previous transaction is NOT signed by the sender of the current transaction.

Only the current transaction (except the signature since that hasn’t been created yet) is signed by the sender.
No, that part is correct. The sighash perimage algorithm takes the current transaction, 0's out all scriptsigs, puts the scriptPubKey of the current input's UTXO in the scriptsig, and then appends the sighash flag to the end. That preimage is then hashed and signed. See https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx and https://github.com/bitcoin/bitcoin/blob/efb4383ef6c69e801ddca160a53e7fb4ee8b156a/src/script/interpreter.cpp#L1176



Some comments in addition to those that DannyHamilton has left:

Quote
remainder commission for miners
Usually that "commission" is called the transaction fee, not a commission.



scriptPubKey's can contain other scripts too, such as P2SH outputs scripts, bare multisig scripts, OP_RETURN scripts, and really any script that fits in the scriptPubKey. It is not just limited to the P2PKH script. Perhaps you should mention that.
2240  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.0.1 Released on: September 19, 2017, 02:06:11 PM


### Miscellaneous
- #9871 `be8ba2c` Add a tree sha512 hash to merge commits (sipa)
- #9821 `d19d45a` util: Specific GetOSRandom for Linux/FreeBSD/OpenBSD (laanwj)
- #9903 `ba80a68` Docs: add details to -rpcclienttimeout doc (ian-kelling)
- #9910 `53c300f` Docs: correct and elaborate -rpcbind doc (ian-kelling)
- #9905 `01b7cda` [contrib] gh-merge: Move second sha512 check to the end (MarcoFalke)
- #9880 `4df8213` Verify Tree-SHA512s in merge commits, enforce sigs are not SHA1 (TheBlueMatt)
- #9932 `00c13ea` Fix verify-commits on travis and always check top commit's tree (TheBlueMatt)
- #9952 `6996e06` Add historical release notes for 0.14.0 (laanwj)
- #9940 `fa99663` Fix verify-commits on OSX, update for new bad Tree-SHA512, point travis to different keyservers (TheBlueMatt)
- #9963 `8040ae6` util: Properly handle errors during log message formatting (laanwj)
- #9984 `cce056d` devtools: Make github-merge compute SHA512 from git, instead of worktree (laanwj)
- #9995 `8bcf934` [doc] clarify blockchain size and pruning (askmike)
- #9734 `0c17afc` Add updating of chainTxData to release process (sipa)
- #10063 `530fcbd` add missing spaces so that markdown recognizes headline (flack)
- #10085 `db1ae54` Docs: remove 'noconnect' option (jlopp)
- #10090 `8e4f7e7` Update bitcoin.conf with example for pruning (coinables)
- #9424 `1a5aaab` Change LogAcceptCategory to use uint32_t rather than sets of strings (gmaxwell)
- #10036 `fbf36ca` Fix init README format to render correctly on github (jlopp)
- #10058 `a2cd0b0` No need to use OpenSSL malloc/free (tjps)
- #10123 `471ed00` Allow debug logs to be excluded from specified component (jnewbery)
- #10104 `fadf078` linearize script: Option to use RPC cookie (achow101)
- #10162 `a3a2160` [trivial] Log calls to getblocktemplate (jnewbery)
- #10155 `928695b` build: Deduplicate version numbers (laanwj)
- #10211 `a86255b` [doc] Contributor fixes & new "finding reviewers" section (kallewoof)
- #10250 `1428f30` Fix some empty vector references (sipa)
- #10270 `95f5e44` Remove Clang workaround for Boost 1.46 (fanquake)
- #10263 `cb007e4` Trivial: fix fee estimate write error log message (CryptAxe)
- #9670 `bd9ec0e` contrib: github-merge improvements (laanwj)
- #10260 `1d75597` [doc] Minor corrections to osx dependencies (fanquake)
- #10189 `750c5a5` devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private (theuni)
- #10322 `bc64b5a` Use hardware timestamps in RNG seeding (sipa)
- #10381 `7f2b9e0` Shadowing warnings are not enabled by default, update doc accordingly (paveljanik)
- #10380 `b6ee855` [doc] Removing comments about dirty entries on txmempool (madeo)
- #10383 `d0c37ee` [logging] log system time and mock time (jnewbery)
- #10404 `b45a52a` doc: Add logging to FinalizeNode() (sdaftuar)
- #10388 `526e839` Output line to debug.log when IsInitialBlockDownload latches to false (morcos)
- #10372 `15254e9` Add perf counter data to GetStrongRandBytes state in scheduler (TheBlueMatt)
- #10461 `55b72f3` Update style guide (sipa)
- #10486 `10e8c0a` devtools: Retry after signing fails in github-merge (laanwj)
- #10447 `f259263` Make bitcoind invalid argument error message specific (laanwj)
- #10495 `6a38b79` contrib: Update location of seeds.txt (laanwj)
- #10469 `b6b150b` Fixing typo in rpcdump.cpp help message (keystrike)
- #10451 `27b9931` contrib/init/bitcoind.openrcconf: Don't disable wallet by default (luke-jr)
- #10323 `00d3692` Update to latest libsecp256k1 master (sipa)
- #10422 `cec9e1e` Fix timestamp in fee estimate debug message (morcos)
- #10566 `5d034ee` [docs] Use the "domain name setup" image (previously unused) in the gitian docs (practicalswift)
- #10534 `a514ac3` Clarify prevector::erase and avoid swap-to-clear (sipa)
- #10575 `22ec768` Header include guideline (sipa)
- #10480 `fbf5d3b` Improve commit-check-script.sh (sipa)
- #10502 `1ad3d4e` scripted-diff: Remove BOOST_FOREACH, Q_FOREACH and PAIRTYPE (jtimon)
- #10377 `b63be2c` Use rdrand as entropy source on supported platforms (sipa)
- #9895 `228c319` Turn TryCreateDirectory() into TryCreateDirectories() (benma)
- #10602 `d76e84a` Make clang-format use C++11 features (practicalswift)
- #10623 `c38f540` doc: Add 0.14.2 release notes (MarcoFalke)
- #10276 `b750b33` contrib/verifybinaries: allow filtering by platform (knocte)
- #10248 `01c4b14` Rewrite addrdb with less duplication using CHashVerifier (sipa)
- #10577 `232508f` Add an explanation of quickly hashing onto a non-power of two range (gmaxwell)
- #10608 `eee398f` Add a comment explaining the use of MAX_BLOCK_BASE_SIZE (gmaxwell)
- #10728 `7397af9` fix typo in help text for removeprunedfunds (AkioNak)
- #10193 `6dbcc74` scripted-diff: Remove #include <boost/foreach.hpp> (jtimon)
- #10676 `379aed0` document script-based return fields for validateaddress (instagibbs)
- #10651 `cef4b5c` Verify binaries from bitcoincore.org and bitcoin.org (TheBlueMatt)
- #10786 `ca4c545` Add PR description to merge commit in github-merge.py (sipa)
- #10812 `c5904e8` [utils] Allow bitcoin-cli's -rpcconnect option to be used with square brackets (jnewbery)
- #10842 `3895e25` Fix incorrect Doxygen tag (@ince → @since). Doxygen parameter name matching (practicalswift)
- #10681 `df0793f` add gdb attach process to test README (instagibbs)
- #10789 `1124328` Punctuation/grammer fixes in rpcwallet.cpp (stevendlander)
- #10655 `78f307b` Properly document target_confirmations in listsinceblock (RHavar)
- #10917 `5c003cb` developer-notes: add reference to snake_case and PascalCase (benma)
- #11003 `4b5a7ce` Docs: Capitalize bullet points in CONTRIBUTING guide (eklitzke)
- #10968 `98aa3f6` Add instructions for parallel gitian builds (coblee)
- #11076 `1c4b9b3` 0.15 release-notes nits: fix redundancy, remove accidental parenthesis & fix range style (practicalswift)
- #11090 `8f0121c` Update contributor names in release-notes.md (Derek701)
- #11056 `cbdd338` disable jni in builds (instagibbs)
- #11080 `2b59cfb` doc: Update build-openbsd for 6.1 (laanwj)
- #11119 `0a6af47` [doc] build-windows: Mention that only trusty works (MarcoFalke)
- #11108 `e8ad101` Changing -txindex requires -reindex, not -reindex-chainstate (TheBlueMatt)
- #9792 `342b9bc` FastRandomContext improvements and switch to ChaCha20 (sipa)
- #9505 `67ed40e` Prevector Quick Destruct (JeremyRubin)
- #10820 `ef37f20` Use cpuid intrinsics instead of asm code (sipa)
- #9999 `a328904` [LevelDB] Plug leveldb logs to bitcoin logs (NicolasDorier)
- #9693 `c5e9e42` Prevent integer overflow in ReadVarInt (gmaxwell)
- #10129 `351d0ad` scheduler: fix sub-second precision with boost < 1.50 (theuni)
- #10153 `fade788` logging: Fix off-by-one for shrinkdebugfile default (MarcoFalke)
- #10305 `c45da32` Fix potential NPD introduced in b297426c (TheBlueMatt)
- #10338 `daf3e7d` Maintain state across GetStrongRandBytes calls (sipa)
- #10544 `a4fe077` Update to LevelDB 1.20 (sipa)
- #10614 `cafe24f` random: fix crash on some 64bit platforms (theuni)
- #10714 `2a09a38` Avoid printing incorrect block indexing time due to uninitialized variable (practicalswift)
- #10837 `8bc6d1f` Fix resource leak on error in GetDevURandom (corebob)
- #10832 `89bb036` init: Factor out AppInitLockDataDirectory and fix startup core dump issue (laanwj)
- #10914 `b995a37` Add missing lock in CScheduler::AreThreadsServicingQueue() (TheBlueMatt)
- #10958 `659c096` Update to latest Bitcoin patches for LevelDB (sipa)
- #10919 `c1c671f` Fix more init bugs (TheBlueMatt)

Credits
=======

Thanks to everyone who directly contributed to this release:

- ロハン ダル
- Ahmad Kazi
- aideca
- Akio Nakamura
- Alex Morcos
- Allan Doensen
- Andres G. Aragoneses
- Andrew Chow
- Angel Leon
- Awemany
- Bob McElrath
- Brian McMichael
- BtcDrak
- Charlie Lee
- Chris Gavin
- Chris Stewart
- Cory Fields
- CryptAxe
- Dag Robole
- Daniel Aleksandersen
- Daniel Cousens
- darksh1ne
- Dimitris Tsapakidis
- Eric Shaw
- Evan Klitzke
- fanquake
- Felix Weis
- flack
- Guido Vranken
- Greg Griffith
- Gregory Maxwell
- Gregory Sanders
- Ian Kelling
- Jack Grigg
- James Evans
- James Hilliard
- Jameson Lopp
- Jeremy Rubin
- Jimmy Song
- João Barbosa
- Johnathan Corgan
- John Newbery
- Jonas Schnelli
- Jorge Timón
- Karl-Johan Alm
- kewde
- KibbledJiveElkZoo
- Kirit Thadaka
- kobake
- Kyle Honeycutt
- Lawrence Nahum
- Luke Dashjr
- Marco Falke
- Marcos Mayorga
- Marijn Stollenga
- Mario Dian
- Mark Friedenbach
- Marko Bencun
- Masahiko Hyuga
- Matt Corallo
- Matthew Zipkin
- Matthias Grundmann
- Michael Goldstein
- Michael Rotarius
- Mikerah
- Mike van Rossum
- Mitchell Cash
- Nicolas Dorier
- Patrick Strateman
- Pavel Janík
- Pavlos Antoniou
- Pavol Rusnak
- Pedro Branco
- Peter Todd
- Pieter Wuille
- practicalswift
- René Nyffenegger
- Ricardo Velhote
- romanornr
- Russell Yanofsky
- Rusty Russell
- Ryan Havar
- shaolinfry
- Shigeya Suzuki
- Simone Madeo
- Spencer Lievens
- Steven D. Lander
- Suhas Daftuar
- Takashi Mitsuta
- Thomas Snider
- Timothy Redaelli
- tintinweb
- tnaka
- Warren Togami
- Wladimir J. van der Laan

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Pages: « 1 ... 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 [112] 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 ... 590 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!