Bitcoin Forum
May 05, 2024, 05:41:24 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 62 »
1  Economy / Economics / Re: "Surprisingly, Tail Emission Is Not Inflationary" -- A post by Peter Todd on: July 10, 2022, 06:17:46 PM
Is it desirable, much less moral, for a percentage of the world's wealth be continually diverted to support mining?   I wouldn't take an absolute hard line position that it wasn't desirable, or even that it wouldn't be moral (at least in so far as it was a system people consented to use)-- but the reasonableness of this depends critically on the amount.   Would 0.001% be acceptable?  I suppose! would 10%? Absolutely not.

Let's suppose a truly devastating war somehow kills half of the global population. For reference, WW2 only managed to kill about 3-4%. We'll also suppose that every single person who was killed lost their private keys, and absolutely no-one left backups to surviving relatives.

If 10% of the world's wealth/year was going to mining after that catastrophic event, 5% of the world's wealth/year must have been getting destroyed in boating accidents.

Sorry, but that's a ridiculous example. And not because of the specific amount: the proportions mean that to get a measly doubling of reward - a reward so low it matches what people lose by accident - half the entire coin supply has to somehow be lost in a massive catastrophe.

If that happens the "transitory" inflation might become extremely market distorting, ultimately harming civilization by directing an unconscionable share of resources to mining or (more likely) causing the system to be abandoned.

In no world is 2x unconscionable where 1x was just fine. Especially when the 1x happened to be what people lose by accident on a regular basis.

The uncertainty of the amount works in the other direction too:  Continued subsidy isn't guaranteed to be enough to support security in any meaningful sense, it could be too small to achieve its intended goal as well as too large.  Because of economic cycles the same scheme could even be both, disruptively overpaying during economic slumps (diverting resources to excess security) and disastrously underpaying during economic booms (failing to achieve the security goals).  Without thinking carefully you might think that sometimes underpaying would still be better than zero subsidy but that isn't clear to me because unpredictability in security is itself a problem because it interferes with compensating behaviors.

Again, there is no way that we can be "disruptively overpaying" with a tail emission approximately equal to what people lose by accident.

...and yes, obviously the continued subsidy isn't guaranteed to be high enough to support security. But as long as Bitcoin is in the billions to trillions market cap range, the level of threat a 0.1% to 1% subsidy is protecting against is the kind of very expensive outside attack that's difficult to predict anyway. All you can do is spend an affordable level of wealth to protect yourself, and hope it'll be enough.

If it's not, there's a good chance that Bitcoin is entirely nonviable anyway, as it's just worth enough to be worth protecting. If Bitcoiner's need to spend 10%+ per year of their entire wealth to protect the network, it may not be worth it at all.

With these points in mind I think Satoshi made a very good decision.  Bitcoin's tail subsidy scheme of zero is the unique amount of tail subsidy guaranteed to (eventually) never overpay. It is the value with the minimum amount of economic uncertainty, excluding security considerations.

That's absurd. Overpaying isn't a concern when you're paying a tiny % of your wealth. What Satoshi did was take a perfectly good system, and build into it a massive long-term unknown in how we'll pay for security.

It's notable that people regularly pay hundreds of times more than strictly necessary in fees. Just look at any block explorer: https://mempool.space/block/000000000000000000030da833111fd3c4ade500b3b96963fadb4523475fe529

That block has a median fee of 15sat/vB, yet some transactions are paying as much as 2007sat/vB. Why? When you're moving millions of dollars fixing your fee estimator to save $10 isn't high on the priority list.

I sure don't care about spending 0.1% or 1% per year of my wealth to keep Bitcoin secure. But I do care that everyone else also chips in so we don't have a tragedy of the commons.

It does make a weaker argument for long term network security, but since tail subsidy schemes are unable to make a strong argument that they're actually able to meaningful improve security (much less guarantee it!) I don't find that weakness particularly compelling.   There are many uncertainties about Bitcoin's security and long term income for mining being insufficient is one of them (probably not even the most concerning one).  Making the economic policy clear and simple is worth it, especially since security isn't going to be clear regardless.  I'm pretty confident that if Bitcoin originally had perpetual subsidy the market would just be further diluted by variants that had different amounts of it. Zero is a pretty strong attractor in the design space, 0.01 vs 0.02% is far less clear.

If you were right, that'd still be happening in alt-coins. So where are the examples?

Being first is much stronger attractor than zero... Especially when "first" in this case could also have just as easily marketed itself as "zero"

I think our experience so far makes a basic case for Bitcoin's security: Bitcoin generates fee income today which is greater than the total (inflation subsidized) income of many altcoins that seem to be going without attack.  Is this a security guarantee?  No, but it's the first test and Bitcoin appears to be passing it.  Assuming it does work I think we're obviously better off with it as it is-- I don't think anyone arguing for tail subsidy would still argue for it if they were confident the system would be secure without it: The only time you can make a clearly moral case for forcing someone to pay someone else is on the basis of necessity.  If Bitcoin's scheme turns out to not work out then users in the future will have many alternatives they could consider-- including adopting Bitcoin variants that are created that have constant subsidy (as tail subsidizers propose) or attempt to achieve security through other means.   To those people, should that future ever come to exist, the discussion will be much simpler though because they'll know if Satoshi's simple economic-effect minimizing scheme works or not, they'll know if alternatives are necessary.

Yes, and by seeding the alternatives in peoples' minds now, it's much easier to have that discussion later. It's also more likely that alternatives will exist that don't make the mistakes Satoshi did.
2  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] TIERION [TNT]Token Sale Starts on 27 July on: August 16, 2017, 12:50:40 AM
The Misleading and Inaccurate Claims Made to Tierion ICO Investors

https://petertodd.org/2017/misleading-and-inaccurate-tierion-ico-claims
3  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] TIERION [TNT]Token Sale Starts on 27 July on: July 28, 2017, 01:30:44 AM
I wrote up some things that you should know about the Tierion ICO:

https://petertodd.org/2017/what-you-need-to-know-about-the-tierion-chainpoint-ico
4  Bitcoin / Bitcoin Discussion / Re: Has Julian Assange met Satoshi Nakamato? on: January 18, 2017, 02:14:38 PM
For the record, I said that *I* met Assange, not Satoshi.

And there's nothing terribly interesting about that: he wanted to know more about Bitcoin, and someone who's a friend of a friend suggested we chat next time I was in London; I'm always happy to talk about Bitcoin to people.
5  Bitcoin / Development & Technical Discussion / Re: Blocksonly mode BW savings, the limits of efficient block xfer, and better relay on: February 26, 2016, 04:09:30 AM
Would these IBLT tx relay techniques also help defeat traffic analysis? Seems to me that they might, which would improve privacy against attackers like the NSA.
6  Bitcoin / Development & Technical Discussion / Re: Why all blocksize propositions are round numbers ? on: January 23, 2016, 09:33:26 PM
Because they're not based on science.
7  Alternate cryptocurrencies / Altcoin Discussion / Re: Poll: Should we rename the alt section the Peter Todd section? on: July 21, 2015, 10:32:23 PM
I heard he woke up today, ate a sandwich and scratched his belly.

FALSE.
8  Bitcoin / Bitcoin Discussion / Re: Freezing BitCoin addresses by regulating miners on: June 14, 2015, 02:09:34 PM
FWIW I've run into a lot of regulatory people who have pretty clear views that Bitcoin mining should be regulated such that addresses are blacklisted or even whitelisted. Obviously that's a goal, not necessarily what they'll succeed in making happen, but that's what the long-term intent is. For instance, one regulator I talked to a few months ago at a conference was *very* clear in her view that the Bitcoin protocol simply must be changed to add verified digital identities to the protocol itself, and mining blocks with transactions without valid identities and/or extending blockchains with non-compliant transactions should be an illegal activity that's prosecuted.
9  Bitcoin / Development & Technical Discussion / Re: Bitcoin GPLed because of GMP? on: June 14, 2015, 02:03:59 PM
https://gmplib.org/

"Since version 6, GMP is distributed under the dual licenses, GNU LGPL v3 and GNU GPL v2. These licenses make the library free to use, share, and improve, and allow you to pass on the result."

What version of GMP does it need?
10  Bitcoin / Bitcoin Discussion / Re: Freezing BitCoin addresses by regulating miners on: June 14, 2015, 12:24:46 AM
Yo, Pete:

Who's the guy who is making a credible threat to subsume Bitcoin under his personal project and is for all intents and purposes the acting 'benevolent dictator' of Bitcoin at this point?  Oh right...Mike Hearn.  Who could have predicted that and assigned status as appropriate???

Credible? We'll see. Smiley

Re: benevolent dictator, nah, we don't have one of those - maybe Wladimir.
11  Bitcoin / Development & Technical Discussion / Re: Will the Stealth BIP (Bitcoin Improvement Proposal) ever be done? on: June 09, 2015, 02:15:53 AM
Long story short, right now I think my time is better spent focusing on more fundemental issues with Bitcoin like scalability.

I've also got no-one interested in funding stealth address development right now; I do need to pay rent!
12  Bitcoin / Development & Technical Discussion / Re: BIP 66 status (miners' votes) on: May 19, 2015, 03:10:38 AM
I guess a pool must have upgraded. 

yep, it's AntPool

It's my buddies at FinalHash.
13  Bitcoin / Bitcoin Discussion / Re: Gavin is an Agent on: May 05, 2015, 08:27:49 AM


Take a look at this picture of Peter Todd, look at his T-Shirt and tell me he's being ironical. You don't wear a T-Shirt with NSA logo unless you idolize them or work for them.

I remember the first time I met Peter Todd, Jeff Garzik introduced him to me, he just seemed to pop out from nowhere. My encounter with him was brief. But I noticed he didn't swallow the bait even then. So I don't really know his real motive being in the Bitcoin game.

lolololololol

I got that shirt from the Electronic Freedom Foundation's booth at 31c3: https://www.eff.org/deeplinks/2013/06/back-popular-demand-nsa-spying-t-shirts-members

Sadly the NSA isn't sufficiently self-aware to sell shirts saying "ALL YOUR DATA" with glowering, red-eyed eagle's... but they should be.

And for the record, I'm a Canadian - I work for CSIS, not the NSA.
14  Bitcoin / Development & Technical Discussion / Re: Proposal for some BIP with KYC elements on: April 25, 2015, 09:17:45 AM
Bitcoin is a consensus protocol to determine the validity of some binary data. Fundamentally, it is just a language. It could not be regulated like regulating a company because there is no one to send to jail and nothing to confiscate. The only way to regulate bitcoin is to control >50% of the hashing power (or to regulate bitcoin users, but bitcoin users != bitcoin).

Quite simply, there'a a high chance this will be the crypto wars all over again. Like the first iteration of the crypto wars, it's a winnable battle, but it is a battle we can lose too.

In any case, regulating Bitcoin by controling >50% of the hashing power is perfectly possible. At minimum there's always the nuclear option of telling the (very few!) chip fabs of the world to add kill switches to the ASICs they make and/or regulate who can buy them.
15  Bitcoin / Development & Technical Discussion / Re: Proposal for some BIP with KYC elements on: April 25, 2015, 08:35:02 AM
There is no reason to store these kind of private encrypted data on the blockchain. The blockchain should be used for storing

  • Public data, or
  • Private data but timestamping is needed

For the case you suggest, users and merchants should digitally sign those receipts and KYC data (with mutually agreed timestamp if needed) and keep it by themselves.

I've actually had this discussion with regulatory/banking types... There's pressure to have the data on the blockchain itself precisely because it forces it to be "sufficiently" public for governments to be happy - many of them want it to be fundamentally impossible to use the blockchain without giving up that information. First step is to be able to know for sure if the data exists.

Obviously pay-to-contract-hash techniques are the sane way to do this stuff... but we don't necessarily have the same goals as regulators do. One of the hard political challenges for people enganging with regulators is convincing them that privacy matters, and any KYC system has to be an add-on, not an inherent part of the system.
16  Bitcoin / Development & Technical Discussion / Re: Proposal for some BIP with KYC elements on: April 25, 2015, 05:47:55 AM
Interfaces for regulation must begin to develop, this is nothing about hurting the Bitcoin user's privacy, we need to break away from that "drug dealer "character and understand that protocol-level standards will create strong ground for that Nobel technology.

Government/bank signed and controlled blockchains are already being worked on that implement all the identity tech you're looking into and more - I've even been told about requirements for these projects to have every single invoice to be uploaded to the blockchain so the government can investigate not only who sent money to whome, but what exactly they were buying. Of course, this is nothing new: credit card processing platforms are already starting to do this stuff too with bigger merchants.

FWIW, the blockchain itself isn't new technology at all. Satoshi's contribution to the state of the art was to figure out how to make the tech work without central authority or identity. What you're doing goes in the exact opposite direction, and is better done in centralized systems; Bitcoin has no advantage over those much faster, cheaper, and more scalable systems other than freedom from regulation.

If you want to work further on this technology, I can pass your name onto companies working in this space. Personally I'm rather dubious about taking on those clients for hopefully obvious reasons...
17  Bitcoin / Development & Technical Discussion / Re: Coinjoin improvement..? on: April 24, 2015, 03:47:36 PM
EDIT:
Found the method used to detect coinjoin txs:
Quote
We defined this pattern as any transaction having more than five inputs and more than five outputs, and looked at how many transactions matched this pattern (which is admittedly only roughly correlated with coinjoins, but as coinjoins are indistinguishable from other transactions we cannot do better than an approximation).
TBH, that sounds like a terrible heuristic to detect coinjoin txs  Roll Eyes

Agreed - very few Darkwallet Coinjoin's will be detected by that huristic. I just checked my wallet and only about %10 of the Coinjoins had more than four outputs. The usual transaction pattern in Darkwallet is for there to be four outputs - sender destination, sender change, mixer duplicated amount, mixer change - and two to four inputs.
18  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [SOFTWARE SALE LIVE] FACTOM - Introducing Honesty to Record-Keeping on: April 21, 2015, 03:51:10 AM
Proof of Existence is the proof of the positive, which can certainly be done in this fashion.  The problem is that it doesn't prove the negative.  Factom allows you to create a Factom Chain where you can not only prove the existence of everything in that chain, but prove no other entries are in the chain.

Peter Todd is working on  a project called Proof Chains (https://github.com/proofchains) that allows you to create a chain of entries in Bitcoin that duplicates Factom's features.  The downside is that your data 1) is directly in the Bitcoin blockchain,

Incorrect for most use-cases; proofchains itself doesn't have any data publishing tech yet anyway.

2) requires Bitcoin's transaction fees (more expensive), 

Often correct, though there are ways to mitigate this issue. Of course, for many applications even $1/proof fees are so cheap as to be effectively free. (e.g. land title registrations)

3) is subject to censorship (by those that don't like this stuff in Bitcoin),

100% incorrect in most use-cases. For the few applications that do need to publish data directly there are many techniques available to make censorship very difficult.

4) requires users to hold the whole Blockchain for their proofs,

Very incorrect. Proofchains techniques work just fine with SPV.

5) is subject to Bitcoin confirmation times,

Correct.

6) requires users to manage and hold Bitcoin wallets to write their data, and

True, although outsourcing the holding of Bitcoins to third parties is pretty easy, and can be done without trusting those third parties.

7) has no means to incentivize the development and support of the code.

Not as exciting as crowdsales, but going to clients and telling them "Hey! I can solve this problem you have." still works reasonable well, provided there actually exists a problem to solve.

Factom seeks to address these and other issues.  It turns out that building a censorship resistant layer over bitcoin to write arbitrary data is just harder than it looks.

It is, which is why I've focused on solving specific problems and building low-level libraries to help solve such problems.
19  Bitcoin / Development & Technical Discussion / Re: Salvaging refund protocols from malleability attacks with P2SH on: April 20, 2015, 08:43:18 PM

We change the protocol so that the escrow payment is to P2SH(2 of 2 Alice2, Bob2) and Alice2 and Bob2 are new keys that they've never used elsewhere and Bob does not know Alice2.

Alice computes the refund but instead of telling bob the refund transactions, she tells Bob only the hash value she wants signed with Bob2.


Is there a library that supports this?

Any Bitcoin library that gives you sufficiently low-level access to transaction signing will support this. For instance my own python-bitcoinlib lets you, as you can see in the P2SH signing example.
20  Bitcoin / Development & Technical Discussion / Re: Storing large data in blockchain on: April 15, 2015, 01:44:54 AM
It is not too difficult to create a tool to get data as a plain text from these transactions (but I do not have interest to do it)

Speaking of tools ... http://bitcoinstrings.com/blk00251.txt Wink

Also here: https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 62 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!