 Show Posts
|
|
Pages: [1] 2 3 »
|
Legitimate use for these things is essentially zero, the only one you see people promote in any detail is the use of loans to avoid capital gains tax but that *does not work*, because that activity is a "constructive sale" as any clueful accountant could tell you.
Is this some consequence of the structure of "defi" lending contracts? I hadn't paid them much attention, but a quick search showed several where you use BTC or ETH as collateral for a loan denominated in some "stablecoin". That leaves you exposed to the risk of (paper) losses if BTC or ETH declines, so it doesn't seem like a constructive sale to me, unless the IRS is treating all cryptocurrencies as substantially similar assets (which might be warranted given the amount of obfuscation alts try to pull off). |
|
|
|
I wonder if these companies are considering that this move may make them attractive targets for asset stripping in the future?
For anyone curious about this idea, perhaps read: https://en.wikipedia.org/wiki/Leveraged_buyout . I had learned about the wave of leveraged buyouts that occurred in the 1980s (taught in the context of how it may have made large organizations more fragile and short-term focused) but hadn't myself connected that with the idea of companies holding significant amounts of bitcoin. |
|
|
|
[...] there isn't much activity in improving the Bitcoin protocol anymore [...]
This statement runs counter to my intuition, so I made a quick comparison. First, I assumed we were talking about the P2P network protocol ("the Bitcoin protocol" could also refer to the consensus protocol, but this conversion seemed to be about networking). Second, I looked at all merges to Bitcoin Core during the six months up to today and the same period five years earlier. Completely subjectively, I made a list of all the commits I thought affected how Bitcoin Core interacted with the protocol in a non-trivial way. Here's the list for the the past six months (2020): $ git log --since=2020-01-09 --until=2020-07-09 --merges --oneline | wc -l
768
abdfd2d0e Merge #19219: Replace automatic bans with discouragement filter
8edfc1715 Merge #19204: p2p: Reduce inv traffic during IBD
28ce05d06 Merge #19260: p2p: disconnect peers that send filterclear + update existing filter msg disconnect logic
73407ff65 Merge #16939: p2p: Delay querying DNS seeds
7d32cce3e Merge #19010: net processing: Add support for getcfheaders
4479eb04d Merge #18960: indexes: Add compact block filter headers cache
c73bd004a Merge #18861: Do not answer GETDATA for to-be-announced tx
553bb3fc3 Merge #18962: net processing: Only send a getheaders for one block in an INV
e45fb7e0d Merge #18877: Serve cfcheckpt requests
7a5767423 Merge #18808: [net processing] Drop unknown types in getdata
0ef0d33f7 Merge #18038: P2P: Mempool tracks locally submitted transactions to improve wallet privacy
67dfd18f4 Merge #16902: O(1) OP_IF/NOTIF/ELSE/ENDIF script implementation
d104aa0ac Merge #17951: Use rolling bloom filter of recent block txs for AlreadyHave() check
01fc5891f Merge #16702: p2p: supplying and using asmap to improve IP bucketing in addrman
Here's the list for the same six-month period five years ago (2015). Note, the merge messages back then didn't include a title, so I placed the subject from one of the commits in that merge in brackets: $ git log --since=2015-01-09 --until=2015-07-09 --merges --oneline | wc -l
321
66e546577 Merge pull request #6310 [f581d3d banlist.dat: store banlist on disk]
41076aad0 Merge pull request #6124 [ffd75ad Enable CHECKLOCKTIMEVERIFY as a standard script verify flag]
e34a8acd9 Merge pull request #6233 [3e91433 Advance pindexLastCommonBlock for blocks in chainActive]
c1fb0e107 Merge pull request #6274 [02a6702 Add option `-alerts` to opt out of alert system]
3a1d3e8f5 Merge pull request #5985 [14d4eef Fix removing of orphan transactions]
8d9f0a606 Merge pull request #5927 [dce8360 Reduce checkpoints' effect on consensus.]
9d6060244 Merge pull request #5875 [9be0e68 Be stricter in processing unrequested blocks]
88a7ead5d Merge pull request #6172 [a1ba077 Ignore getheaders requests when not synced.]
9f7809f6c Merge pull request #5976 [8ba7f84 Reduce download timeouts as blocks arrive]
e9af4e65b Merge pull request #5947 [36cba8f Alert if it is very likely we are getting a bad chain]
7bf5d5efa Merge pull request #5918 [f7303f9 Use equivalent PoW for non-main-chain requests]
5048465fc Merge pull request #5662 [00dcaf4 Change download logic to allow calling getheaders/getdata on inbound peers]
71900b442 Merge pull request #6029 [a784f90 Cap nAttempts penalty at 8 and switch to pow instead of a division loop.]
27e8d224e Merge pull request #5945 [ad9e86d Keep mempool consistent during block-reorgs]
f7dea1cba Merge pull request #5941 [1d21ba2 Scale up addrman]
29fef0b90 Merge pull request #5360 [9c27379 Reduce fingerprinting through timestamps in 'addr' messages.]
c1b723c30 Merge pull request #5442 [dca799e Ignore getaddr messages on Outbound connections.]
51377c2db Merge pull request #5843 [ba04c4a Limit message sizes before transfer]
fcf646c9b Merge pull request #5286 [a930658 Change the default maximum OP_RETURN size to 80 bytes]
6ee87f9bc Merge pull request #5647 [3ff735c Increase block download timeout base from 10 to 20 minutes.]
41e6e4cab Merge pull request #5713 [5a47811 BIP66 changeover logic (Pieter Wuille)]
de8b9ab75 Merge pull request #5608 [9161303 Introduce 10 minute block download timeout]
So there were 22 (subjectively) notable merges in 2015 and 14 notable merges in 2020, a 35% decrease in the number of merges. In both cases, an overwhelming majority of the changes are tweaks to the existing logic mean to improve security, privacy, or reliability rather than more significant extensions of the protocol. Looking at the titles of the merges, and again very subjectively, I think I'd consider the aggregate of the changes made in 2015 to be even more than 35% useful than the 2020 changes, so the gap between the years is arguably larger than suggested by just the numbers. However, based on these data, I don't personally agree that "there isn't much activity in improving the Bitcoin protocol anymore." The rate of change does seem slower, but I think it's far from stagnant. |
|
|
|
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. |
|
|
|
Both domains were last updated on November 24 last year: Domain Name: BITCOINTALK.ORG
Registry Domain ID: D162601474-LROR
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
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: whois.namecheap.com
Registrar URL: http://www.namecheap.com
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: Hey, FYI, the .org TLD was just sold to a private company.[1] I noticed Bitcoin.org 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). -Dave [1] https://savedotorg.org/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). |
|
|
|
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 https://bitcoinops.org/workshops/#taproot-workshop, 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 https://diyhpl.us/wiki/transcripts/bitcoinops/schnorr-taproot-workshop-2019/notes/ : 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. |
|
|
|
AFAIK, blockchain.info 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 Blockchain.info, 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.) |
|
|
|
|
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?
|
|
|
|
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.) |
|
|
|
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! |
|
|
|
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. 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, bitcoin.org 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 (Bitcoin.me) 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. |
|
|
|
|
super3:
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.
|
|
|
|
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! |
|
|
|
piotr_n: 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: https://bitcoin.org/en/developer-reference#op-codesAs 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! |
|
|
|
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: https://bitcoin.org/en/developer-documentationWe'll be adding more content over the next few monhs, so check back often! Thanks! |
|
|
|
Notes about where to contribute to the current effort from the bitcoin-development mailing list: |
|
|
|
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: http://www.youtube.com/watch?v=r0BXnWlnIi4 |
|
|
|
|
