Bitcoin Forum
July 04, 2020, 02:59:17 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Bitcoin / Development & Technical Discussion / Re: New Mempool Observation: The daily BitMEX broadcast at 13:08 UTC on: May 13, 2020, 12:40:27 PM
I thought about creating a service similar to what you describe. Reasons I didn't are that [...]  I'd be (at least partially) competing with the Bitcoin Optech guys.

Please, please, please don't hesitate to compete with us!  Although Optech is technically a for-profit company, we operate like a non-profit, have only modest revenue, and almost all of us are contributing for free (or through salaries paid for by other organizations, like Chaincode or Square Crypto).  We occasionally write about fee management because we think it's important, but there's plenty of other important things we could be doing with our time (both as individuals and as a team).

Early on, we made a decision to focus on producing educational material and holding workshops rather than offering direct consulting---so you (or anyone else) working directly with companies to optimize their spending would be a complimentary service, not a competitive one.
2  Other / Meta / Re: Domain name update on: April 19, 2020, 04:22:09 PM
Both domains were last updated on November 24 last year:
Registry Domain ID: D162601474-LROR
Registrar WHOIS Server:
Registrar URL:
Updated Date: 2019-11-24T14:01:10Z
Creation Date: 2011-06-24T05:19:00Z
Registry Expiry Date: 2029-06-24T05:19:00Z
Domain Name: BITCOIN.ORG
Registry Domain ID: D153621148-LROR
Registrar WHOIS Server:
Registrar URL:
Updated Date: 2019-11-24T13:58:35Z
Creation Date: 2008-08-18T13:19:55Z
Registry Expiry Date: 2029-08-18T13:19:55Z

That update was likely the result of my prompting.  On 23 November (my local time), I emailed several people I knew who owned .org domains encouraging them to renew as far in the future as possible because the .org registry was being sold.  Here's a copy of the email I sent C°bra:


FYI, the .org TLD was just sold to a private company.[1]  I noticed is due to expire in two years; you may want to renew now to
the maximum of 10 years before the new .org TLD owners raise
prices (some TLDs charge many thousands of dollars per year for the
"bitcoin" name in their TLD).



C°bra replied thanking me for the tip and saying that he'd update both domains, although he wasn't sure it was strictly necessary (indeed, so far, I don't think renewal fees have increased much).
3  Bitcoin / Development & Technical Discussion / Re: OP_CHECKTEMPLATEVERIFY on: January 27, 2020, 11:32:45 AM
How does this differ from Taproot, which also held workshops? I actually didn't know about the workshops until after they happened, I never received a notice that they were occurring, otherwise I would have attended.

If you're referring to, please note those were private training sessions for Optech member companies (who all pay an annual fee in part so that we can produce training material for them).  The workshops did not involve any of the primary contributors to taproot (edit: this is incorrect: Pieter Wuille attended the SF workshop and Andrew Poelstra attended the NYC workshop) and did not involve any protocol development.  Indeed, here are some quotes from Bryan Bishop's rough transcript of the New York session :

Why Bitcoin Optech?

Why are we doing this? Why is Bitcoin Optech involved? We started Optech 18 months ago because we wanted to help bitcoin companies adopt scaling technologies. At the time that was batching and fee estimation, but we're also looking at what's coming along like Schnorr, Taproot, eltoo maybe. We're also helping to get Schnorr and Taproot reviewed and later implemented by services. So we want to help drive adoption of scaling tech to bitcoin.

Why this workshop?

Schnorr/taproot is still a few months or a year out. We still want to share the current thinking around Schnorr and taproot. Pieter and Andrew have been working very hard on this proposal. They want to share with people in the industry what the current thinking is, around taproot. We want to give you guys a chance to play with the technology, write code, and see what you can do with the technology. We also want you involved in the feedback process. Right now the proposal is going through community feedback right now, and we want you guys to be able to take part of that feedback process since you guys are the ones who will be implementing it out when this gets rolled out.

A few warnings

Schonrr/taproot is a proposal. It will change. In fact, it has changed. In our notebooks, we were using 33 byte public keys. But in the proposal, they have now switched to 32 byte public keys.

There is no roadmap. Nobody is in charge of bitcoin and says when we can make a consensus change. This stuff could be rolled out and implemented, it could be in 6 months or many years, we don't know. It probably won't be 1 month.

Also, all of the code you see today is only for educational purposes, please don't spend real money with our libraries. They are not secure.

I'm sorry if there was any confusion about these workshops somehow being official.
4  Bitcoin / Bitcoin Discussion / Re: After segwit BTC is not Bitcoin anymore! on: December 21, 2019, 02:57:18 PM
I think a lot of people would be more interested in a new message signing format that was based on signing an invalid (forever timelocked or whatever) transaction, because that could be generic for _all_ addresses including multisig and script using ones... Perhaps it could be based on the PSBT message format... but there too it doesn't seem like there is enough interest for anyone to go about implementing it either.

Are you aware of BIP322 and its PR for Bitcoin Core?  Here's also a short summary and some links to info about its development history.
5  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.)
6  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?
7  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.
8  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.)

9  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!
10  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).
11  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:
12  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.
13  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.
14  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!
15  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!
16  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!
17  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 .
18  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:
19  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
20  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. :-)
Pages: [1] 2 3 »
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!