Bitcoin Forum
January 19, 2019, 11:41:28 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 25, 2018, 11:28:28 AM
AFAIK, has hired 1 employee (although I can't recall which whop) and there was a Xapo listing for a Bitcoin Core developer some time ago (I'm not sure what happened with that). Other than those two, I haven't seen other examples of companies doing this.

Last I heard, Sjors Provoost works for, Anthony (AJ) Towns works for Xapo, and Jim Posen works for Coinbase. Blockstream employees Pieter Wuille, Jorge Timon, Gregory Sanders, and several other contributors (plus two C-Lightning devs)  Several companies also help support the Media Lab's Digital Currency Initiative (DCI) that employees Wladimir van der Laan and Cory Fields (as well as several other open source Bitcoin contributors who don't normally focus on Bitcoin Core).

The other major source of employment for Bitcoin Core work is ChainCode Labs.

(I could be forgetting some companies; if so, sorry.)
2  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 24, 2018, 11:16:09 PM
I'm disappointed that almost everyone posting in this thread is making suggestions about what other people should do rather than thinking of ways to contribute themselves.

I plan to open at least one PR a month adding a useful new test to Bitcoin Core, or significantly improving an existing test, with the first PR to be opened by 31 October 2018.

What do the rest of you plan to do?
3  Bitcoin / Electrum / Re: Get block header electrum plugin on: July 06, 2015, 01:52:11 AM
I added information about finding a safe server with Electrum here:

If you find any more servers whose banner lists a safe version, please add it to that list.
4  Bitcoin / Development & Technical Discussion / Re: Bloom filter examples? on: January 13, 2015, 12:00:08 PM
At a guess, the payload would be something like this:

01 ......... Filter bytes: 1
0000 ....... Filter: 00000000
00000000 ... nHashFuncs: 0
00000000 ... nTweak: 0/none
00 ......... nFlags: BLOOM_UPDATE_NONE

You'd have to determine for yourself whether an empty filter or an nHashFuncs of zero is permitted.  It might even be possible to set nFilterBytes to 0 and omit the filter field entirely.

Note that you don't need a filter to inhibit receiving transaction invs---that's the default connection mode if you set the relay flag to 0x00 in the version message.  (This would normally be done in conduction with setting the services bitfield to 0x0000000000000000 to indicate you're not running a full node.)

5  Bitcoin / Development & Technical Discussion / Re: fork detection behavior on: January 03, 2015, 02:26:47 PM
The quote is out of context, so it isn't clear that we're talking about a non-upgraded node after a hard fork.  In that case, the non-upgraded node does not think the stronger chain is valid (because it breaks some consensus rule), so it will not accept it as the local best block chain.  The error/alertnotify is to tell you something is wrong.  For reference, that section of the docs was written based on the code is this function.

I'll push a minor revision to the quoted sentence so it's more clear and harder to take out of context.  Thanks!
6  Bitcoin / Development & Technical Discussion / Re: Bloom filter examples? on: January 03, 2015, 02:07:19 PM
We recently added docs about bloom filters and merkleblocks to the developer documentation.  You probably want to read this first:

And then look at the Python example here:

I also agree with Mike: I found reading the BitcoinJ sources very useful when writing the above linked documentation (and, of course, I depended on BIP37 for design details).
7  Bitcoin / Development & Technical Discussion / Re: Transaction id hashing and var_ints on: November 16, 2014, 03:17:32 PM
It looks to me like CompactSize requires the smallest possible encoding.  See:

It also looks like there are some tests to ensure non-canonical compatSize uints are forbidden in the test cases.  See:
8  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: October 01, 2014, 07:36:41 PM
The developers guide already lists the command line arguments.  The conf file is a subset of those commands.

Incorrect.  The developers reference describes Remote Procedure Calls (RPCs) which have nothing to do with the configuration files. is also doing a page on running your own node (see  ... You are going to need the conf file explanation on that page

Incorrect. I opened the issue proposing that page based on a bitcoin-devel mailing list discussion and, as the issue says, I'm delaying writing that page until there's a setup-free package which allows Bitcoin Core to run as a background service---that means no config file editing will be required.

All the information is already within, or will be within, and there is no purpose in trying to change the Wiki to make a second copy of the same information.

Incorrect, as described above.

> if Luke Jr. is going to come in and deny/change the edits so I would not waste my time trying to do that.

Scurrilous.  Luke-Jr is the one who suggested you update the Wiki, so he's unlikely to reject a quality contribution.

You have already told me the only reason you denied posting the video I had made was because of my "attitude" which is not a legitimate reason.

I disagree. The video promotes your website ( and so your behavior is highly relevant. Based on the calumnious statements you've made in the pull request, issues, email correspondence, and this thread, I would recommend people stay away from you and your website.
9  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: May 25, 2014, 07:12:16 PM

Greg Sanders and myself (Dave Harding) wrote almost all of the original text. The in-text illustrations were all done by me, I think. Sa´vann Carignan (blockgenesis) was managing editor, integrated the text into the website (along with icon development), and generally did the many small necessary things to keep the project on track and productive. I'd call us three the current core docs team (but more people are welcome!).

Mike Hearn brought most of us together, provided a large number of invaluable early reviews, and more ongoing feedback to the degree his busy schedule allowed.  Knowing we had the explicit support of at least one core dev was highly motivating, and I think we're all deeply appreciative that Mike was willing to lend his time to our endeavor.

Tom Geller provided line-level editing of the first-written section of the guide, the Block Chain section, as well as creating the style guide we continue to follow.

Chris Beams has been continually providing reviews, feedback, testing, and suggestions both on the text and the website presentation.

Quite a few other people have contributed, although in ways that are harder to track. For example, Greg and myself used the Bitcoin Wiki extensively for research, and the authors of those articles deserve a huge thanks. We're also incredibly grateful to everyone who reviewed parts of our text for accuracy---even if they didn't find any mistakes.

I hope I haven't forgotten anyone.

As for Bitcoin addresses, Sa´vann (blockgenesis) received some docs thank-you donations and has already made arrangements to split them between himself, Greg, and myself once they stop coming in. He's been receiving those donations to the address in his sig, 18XXXQs1vAQGBAZbXKA322r9Zy1nZac2H4.  If you send a tip because of the docs, you really should mention it to him that it was for the docs.

However, speaking only for myself, I think the best contributions we can receive are additional reviews for accuracy and help spreading the word about these docs.
10  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: May 24, 2014, 11:33:08 PM
I already figured that you mean applications based on bitcoind's RCP API, or an API of other components that your firm is busy developing.

There is no firm.  This is volunteer-written documentation for the entire Bitcoin community.  However, we do have to start somewhere---and I can't think of anywhere better to start than Bitcoin Core.

I'm sorry if I confused you.  Thanks again for your comments!
11  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: May 24, 2014, 08:27:50 PM

Our audience description says that we're focusing on application developers, which (in my mind) means that we prioritize writing documentation for developers who will use libraries or Bitcoin Core RPCs for the underlying network communication.

Once we've covered the topics application developers need to know, I'm happy to move on to topics library developers or core re-implementors need to know.

As for opcodes, we describe all the opcodes used in standard transactions here:

As for cross-reference linking, we use it extensively---there are over 2,000 links in the Guide and Reference.  Just hover your mouse over a paragraph to see all of the internal links appear in blue.  You can further hover your mouse over a term to get a brief description, and then click on it to go to the full description.

We really did put a lot of work into trying to design the docs to be useful for developers at all stages, from Bitcoin neophyte to core dev.  Given more time (or more volunteers!) we'll be able to fulfill our core mission and expand the docs to cover more and more parts of Bitcoin.

Thanks for your comments!
12  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: May 24, 2014, 07:44:54 PM
Hi, piortr_n.

Did you checkout both the guide and the reference pages?  The guide is aimed at new developers who need to learn how Bitcoin works.  The reference is aimed at the developers who know how the general system works but need, as you say, tables and short explanations (which we've put all on one page for easy in-browser Ctrl-f searching).

Both are linked to from the main page, which also links to other useful resources:

We'll be adding more content over the next few monhs, so check back often!  Thanks!
13  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: May 11, 2014, 01:40:08 PM
Notes about where to contribute to the current effort from the bitcoin-development mailing list:

Quote from: blockgenesis
A new "Developer Documentation" section should be soon merged on .

Live Preview:

GitHub Pull Request:

Bitcointalk Thread:

We've worked hard to come up with good quality documentation and general
feedback has been positive. Reviews from experienced Bitcoin developers
would now be much appreciated. You are cordially invited to help
proofread the documentation so it can be published soon!

*Please avoid commenting on the mailing list* to not spam everyone. See
the pull request for instructions. Comments should go on the pull
request or bitcoin-documentation mailing list!forum/bitcoin-documentation .
14  Bitcoin / Bitcoin Technical Support / Re: Why does "createrawtransaction $(decoderawtransaction $hexString)" not work? on: April 28, 2014, 02:32:58 PM
I expected a transaction with a locktime in the future to be broadcast and confirmed, but that the outputs wouldn't be spendable until the locktime was reached (except the miner fee). This seems to have many advantages:

1. No need for a seperate service to store such transactions, they're in the blockchain
2. No risk of the sender double-spending his part of the transaction
3. Only one private key must be kept secret: the recipients
4. No danger that the transaction format may be changed in the future, making the transaction useless
5. Much simpler end-user experience - the coins appear in the wallet, but aren't spendable. No need to fiddle with transactions.

Can someone explain why it can't be implemented this way? Every node would have to start checking whether inputs come from transactions which haven't reached their locktime, but this seems fairly minor.

Locktime was initially designed to be used with transaction replacement---the replacing of one version of a transaction with another.  This is a feature used today in "contracts" such as a micropayment channel.

Obviously, if time locked transactions are added to the block chain, you can't do transaction replacement.

Now my question: why would you want to irrevocably pay someone but not let them spend the money until a later point?  I kind of like the current method where I can give someone a time locked transaction but rescind (double-spend) it prior to the locktime maturing.   With this method, you can accomplish everything on your list except for #4:

1. No need for a separate service: the time locked transaction can be stored in the same wallet as the receiver's private key.  If you lose your private key, then the transaction is worthless to you anyway.

2. No risk of the spender double-spending if you use a two-hop transaction where the first transaction goes to a 2-of-2 multisig output that has one key each from the spender and the receiver.

3. Only one private key needs to be kept secret if the spender deletes his private key.

4. (You do not get protection against the transaction format changing.)

5. Simple UIs have already been written for micropayment channels which use time locked transactions.  For example:
15  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: April 12, 2014, 07:59:38 PM

We could use a little advice about what's relevant to wallet authors when it comes to choosing which inputs to select for making a new payment.  We described three options:

* A merge avoidance algorithm makes it harder for outsiders looking at block chain data to figure out how many satoshis the receiver has earned, spent, and saved.

* A last-in-first-out (LIFO) algorithm spends newly acquired satoshis while there's still double spend risk, possibly pushing that risk on to others. This can be good for the receiver's balance sheet but possibly bad for their reputation.

* A first-in-first-out (FIFO) algorithm spends the oldest satoshis first, which can help ensure that the receiver's payments always confirm

We were thinking about cutting out FIFO because it doesn't seem very useful (except for being reliable and easy to implement).  We were further discussing whether we should cut out LIFO---which might be useful for some applications---in order to emphesize the privacy benefits of merge avoidance.

However, none of us writers/editors have any practical experience here, so we would appreciate some developer feedback about what you need to know.  Here's a direct link to the input-selection section and our GitHub discussion of the issue.

A quick trace of Electrum's source code (which I happend to have handy) made it seem like it used FIFO.

Thanks, -Dave
16  Bitcoin / Development & Technical Discussion / Re: Finally a question about Bitcoin that I could not answer. on: April 03, 2014, 03:32:20 PM
Hi, Jan.

We'd absolute love any help!  We're mostly guessing about what developers need to know, so feedback based on your experience with Mycelium would be hugely appreciated.  For example, what assumptions made by other documentation has tripped you up?[1]  Which BIPs have you found hard to understand?[2]  What important things just aren't documented elsewhere?[3]



[1] As an example of assumptions, one developer told us that the standard format for describing scripts is confusing to new devs because it doesn't mention the op-push-data codes that must be used.  It just assumes you know about them. We revised the documentation based on his feedback.

[2] As an example of finding documentation hard to understand, when I wrote a quick test implementation of BIP70, trying to figure out one particular sentence from BIP70 cost me three hours of time.

[3] I'm sure there are plenty of examples of undocumented things. :-)
17  Bitcoin / Development & Technical Discussion / Re: Finally a question about Bitcoin that I could not answer. on: April 02, 2014, 02:14:25 PM

We've been working on a developer guide for which might be what you're looking for.  We have a forum thread, GitHub repository, and a demo site.

We're actively looking for writers and reviewers, so if you'd like to help, please see the forum thread above.

Thanks!, -Dave
18  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: April 02, 2014, 02:08:23 PM

The payment processing section (including BIP70 payment requests) has been added to the devguide.  Comments and suggestions are welcome on the pull request.

(Please comment there even though the pull request is closed.  Every comment posted will be read and replied to.)

Thanks to Sa´vann's late-night efforts, you can read the new section in nicely-formatted HTML on the demo site.

General questions or comments should be sent here, the mailing list, or submitted as an issue.

Thanks!, -Dave
19  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: March 31, 2014, 07:35:44 PM
Edit:  After reading through the Bitcoin Core source code for an embarrassingly long time, I figured out that this paragraph from BIP70,

signature: digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data.

means to do this:

request.signature = ""

before doing this:

request.signature = sign(priv_key, request.SerializeToString(), "sha256")

Thanks to everyone who read my previous post.
20  Bitcoin / Development & Technical Discussion / Re: Developer Guide on writers/reviewers needed on: March 17, 2014, 07:20:01 PM
Pages: [1] 2 3 » is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!