It would be wise to know the purpose of fees before attempting such proposals.  Fees have nothing whatsoever to do with the value sent.  Rather, they bid on a share of a limited global resource:  Block capacity.  It is easily possible for a huge transaction to transmit no value at all, via OP_RETURN; whereas a transaction which sends one huge input to one output could transmit a king’s fortune while using only a few hundred bytes of network resources.

Moreover, added to block reward and multiplied by the market value of Bitcoin, fees increase the total value of mining; and the value of mining is critical to Bitcoin security:

---

Actually, the whole network would implode and grind to a halt.  People think it’s bad now?  Imagine if a max fee were set by a ratio to the value sent, per OP’s suggestion.  Somebody out there would generate a bunch of OP_RETURN transactions containing cute cat photos (or much worse—I mean of course, photos of cryptokitties).  0×cap_ratio=0, for any value of cap_ratio; thus, those transactions would be free.  Ultimate results are left as an exercise to the reader.

---

Time to go nuclear with MR POWA?  Nah.  I wouldn’t want to hurt the decent miners who pool up with p2pool, slush, et al.

In my opinion, the solution to huge, centralized malicious miners is to commoditize SHA-256 ASICs.  I’ve said before that a reasonably powerful ASIC should be inexpensive and readily available as a mass-market GPU.  Now I will go one step further:  The damn things should be built into novelty USB coffee warmers.  Do you really want to sock it to Jihan?

Any open-source hardware experts want to cook up a design and crowdfund an initial production run?  Yes, I know it’s not so easy.  But there could be much money in this, too.  Somebody with an appropriate professional skillset should work on it.

Yes, a few posts later.  Lovely.  Do you know the FUD effect your original post may have, when idiots see it?  Whatever your intentions, that was an extraordinary mistake.

For my part, I quoted your correction in my post; thus, it’s clear that I did read the discussion up to that point.  I also provided a link to Satoshi’s discussion of why he didn’t have the bitcoin dot-com domain name, back in March of 2010.  I presume you had not seen that; most people haven’t.  (N.b. that as far as I know, the domain has changed hands since then—and has never been in the hands of any decent Bitcoiner.)  When I wrote my reply, as you must surely understand, I did not write only it to you; I covered the topic adequately for you, and for anybody else who might read through this thread.

But I must here give you a friendly tip:  If you expect for people on Internet forums nowadays to actually read anything before shooting their mouths off, prepare to be disappointed.  I know that I am, seemingly in perpetuity.

---

Edit:  P.S.:  I suggest that edit your original post to add a note like this one, appending the correction to your original post.  That way, people numbskulls who only read the first post will actually see your self-correction—with more graceful results all around.  I do not recommend editing the substance of your post.  Not only would that be dishonestly rewriting history; but it would also make you look like a fool, since your original post is fully quoted in multiple other posts in the thread for anybody to see.

Technically, if every single transaction was sent with a 1 sat/byte fee, then the large mining farms would shut down, difficulty would plummet—and Bitcoin would lose its Byzantine fault-tolerant security against double-spends and rewriting of the blockchain history.

FEES HELP KEEP THE NETWORK SAFE.  The higher the value of Bitcoin, the more safety it needs.  The higher the potential profit or miners, the more heavily miners compete with each other—thus raising difficulty—thus making it more difficult, and astronomically more expensive for any entity to perform a “51% attack” and the like.

Bitcoin did not need high mining difficulty, when it was a toy and every bitcoin was worth 30¢.  Then, yes, it was fine for difficulty to be low so that anybody could mine on a desktop PC’s CPU.  Now that the network protects the exchange-value equivalent of hundreds of billions of dollars, it needs commensurately high hashrate.

Most people do not understand how the fee market interacts with the security of Bitcoin.

That’s a huge “if”.  Even if a practical quantum computer existed, what makes you expect it to break public key cryptography “in seconds”?  Please remember that even today, a security level of (say) 80 bits is considered far too weak; and yet, it is not something you should consider “broken in seconds”.  (Try to do 2^80 work, if you don’t believe me.)

But arguendo, assuming your “if”:  Well, then, yes, an attacker could race you to double-spend, or even mine his own block to double-spend your coins.  (I assume that an attacker equipped to break PK crypto “in seconds” could also have a big advantage over other miners.)  In that case, I would be very worried about Bitcoin security.  I would likewise be worried about the security of the entire Internet, the banking system, and everything else which would be totally shattered (worse than Bitcoin) in your scenario.  What would I do about my PGP keys?  My TLS?  My SSH?  Everything else?  Bitcoin would be one of the only things left with even a little bit of security.

---

I see that earlier, haltingprobability wrote me an excellent reply.  I should get back to that....

[Note:  I was in the middle of writing this when ranochigo posted.  Thus some of the redundancy.]


If you don’t want technical discussion, then why are you posting in “Development & Technical Discussion”?  Ask in another forum.  I dumb things down for people over there, or I stay away.  Also, I personally couldn’t care less what you say is “good for ordinary people”.

But if you desire a technical education, this is an excellent place.


You never defined a “fake” transaction.  I will infer a precise definition:  A transaction which does one or more of (0) violating consensus rules, and/or (1) spending inputs which were already spent (viz. a double-spend tx).

Protection against (1) is the purpose and the only purpose of miners and “confirmation”.  The technical term is that “confirmation” provides Byzantine fault tolerance in the ordering of transactions.  Ordering is important, that is what chooses between multiple conflicting transactions in a double-spend scenario.  “Byzantine fault tolerance” means in effect that untrusted and mutually untrusting parties with unreliable communications can reliably converge on a common agreement, excluding malicious cheaters.

Full protection against (0) is built into Core, which validates each and every transaction according to a stringent set of rules.  Every bit and byte of each and every transaction must pass validation, or else the whole transaction is simply discarded.  Full nodes also validate whole blocks of transactions, according to yet more rules; this prevents malicious miners from messing with the network.  A Core node follows whichever fully valid chain has the highest total proof-of-work.

If a transaction passes all consensus rule validation and has been “confirmed”, then by definition it is not fake.

If you can’t run a full node, then what you are saying is that you can’t have full validation.  There’s no magical means to wave that away.  The better light clients (such as Electrum) are good enough for most light consumer use; but they will never have the security of a Core node.


I haven’t bothered to pick that apart and see what’s going on.  But as kahc noted, it’s probably just exploiting a bug in blockchain.info’s (notoriously buggy) software.  Solution:  Run Core.


The only way to protect against double-spends is with confirmations.  Unconfirmed transactions are never safe.  They always have some possibility of being overridden with a double-spend.  It is impossible that you could “detect” that; and if there were such a way, we wouldn’t need miners.  Whatever you are doing, it is not achieving what you suppose.


Segwit, which activated 24th August 2017 at Block #481824, was a “softfork”.  It still permits old-style transactions.  Indeed, if your address starts with a “1”, then you are still sending non-Segwit transactions and vastly overpaying in fees.  This is important if you want to save on fees (and also help the network), so I will briefly explain.

Oversimplifying a bit:  Whether or not a transaction is a Segwit tx is determined by the address of the sender.  So if you want to send Segwit tx and get a sharp fee discount, you need to use a Segwit address.  There are two kinds of Segwit addresses:

• Backwards-compatible P2WPKH-nested-in-P2SH addresses, such as the one in my signature: 36finjay27E5XPDtSdLEsPR1RypfhNW8D8.  These start with a “3”; but not all addresses starting with a “3” are Segwit addresses (just as all dogs are animals, but not all animals are dogs).  There is no way to distinguish whether or not a “3” address is Segwit, just by looking at it.  These addresses have some disadvantages, but one important advantage:  Every Bitcoin client made in the past few years can send money to them.
• Bech32 addresses, which I call “Bravo Charlie One” addresses because they always start with “bc1”.  Those look like this:  bc1qnym7k9hfl77zgrstcrjhphm0llne5j4w0m3fuu  That’s the Bitcoin address of the future, redesigned with error-correcting codes and no upper/lowercase distinction.  But Bech32 has one temporary disadvantage:  Only people who have upgraded to the newest software can send money to it.  I want people to send me money, so I’m still using nested P2SH; I hope to switch to Bech32 in about 6–12 months.

Ok, bye!  Don’t let the door hit your butt on the way out.

Bitcoin doesn’t need you.  Big money is now involved, and big money is competing with itself.  I am perpetually amused by how people don’t realize that even if you’re a “whale”, you need Bitcoin and Bitcoin does not need you.  You’re not doing Bitcoin any favours.

So sell now, SELL SELL SELL, dump your BTC, and go away.  You will be crying a few years from now, when the 2017 market looks like the 2012 market does now.  But by then, it will be too late; and neither Bitcoin nor I will give a damn what happens to you.

I’m happy to help people who love Bitcoin.  I volunteer many hours of my time explaining how to get an instant fee discount with Segwit, how to generate nested P2SH Segwit addresses with the popular Electrum wallet, etc., etc.  See above!  But if you “choose another coin very soon”, I will be pleased to laugh at your future regrets.

Stop spamming new topics about BCH.  This is the Bitcoin Forum, for discussion of Bitcoin.  Go to the altcoin forum if you wish to discuss altcoins.

“New” carries a chance of being a scamcoin shill.  Just FYI.  I think you probably came here for reasonable discussion; but when launching straight into a controversy, you should understand that it’s better to prove yourself by your behavior than to ask upfront for niceness.


Say what?  Bitcoin has no “co-founder”.  What could you possibly be talking about?



Oh, that.  According to Bitcoin’s founder, Satoshi Nakamoto, the domain name bitcoin.COM never had anything to do with Bitcoin!  If you see people confused over the domain name, please spread that link—and also, give people the correct link to bitcoin.ORG, the domain name originally registered by Satoshi.  (FYI also, this forum used to be hosted under bitcoin.ORG before it got its own domain name.)


drpixou, either you are lying, or you are stupid.  Pick which one.  There is only one Bitcoin.  There is only one Bitcoin Core; it never “split”.  The misleading misnamed “Bitcoin Cash” is a scam backed by Jihan Wu of Bitmain, a miner who is believed to be covertly exploiting the ASICBOOST security vulnerability which Bitcoin fixed with Segwit.  (So-called “Bitcoin Cash” scamcoin is still vulnerable.)  It is promoted by Roger Ver, a sleazy thug who happened to get his hands on the domain name bitcoin.COM.  It is trash, not cash.  So-called “Segwit2X”, also misnamed and mis-advertized, was a hostile takeover attempt which started with the so-called “New York Agreement”.  Bitcoin Core has been opposed to this nonsense all along.


Say what?  No, BCH is far behind Bitcoin in technology.  Bitcoin has the Segwit upgrade.  Bitcoin will soon have Schnorr signatures, MAST, and possibly sidechains.  Bitcoin will soon have L2 scaling with the Lightning Network.  BCH has none of these technologies.


Last month, I laughed as the sheep got sheared.  No, I am not nice—at least, not to scammers and morons.  Meanwhile, with all the blatant market manipulation involving breathtaking amounts of money, Roger Ver and his cronies managed to knock Bitcoin down about 30% for all of a few days.  Bitcoin rebounded to a new all-time high within the week, whilst BCH crashed from its peak and lots of newbs lost all their money.  (I know that you know this; I am giving capsule history for the newbs.)

What, do you suggest that you expect them to choose the lowest fees first?  Or do you expect them to ignore fees?  Do you have any idea how stupid that sounds?

Each block has a certain capacity, calculated by block weight.  Only 4000000 bytes of weight will fit in a block, pursuant to the equation set forth in BIP 141 and the static const unsigned int MAX_BLOCK_WEIGHT declared in src/consensus/consensus.h.  If there are too many transactions to fit, then miners have only one sensible way to choose:  Pick the transactions which offer higher fees per weight unit.  From the miner’s perspective, anything else would be throwing money away.  What do you really expect them to do?


Graded F- in the analogies section.

What do you even mean by a “fake” transaction?  That’s a meaningless phrase which could mean anything.  Generally, no, fake transactions are not possible.

If you’re worried about unconfirmed transactions, well—you should be.  Wait for confirmation.  Unconfirmed transactions are insecure; they could turn out to be “fake” in the sense of a being overridden with a double-spend.  That’s why the process of confirming transactions exists in the first place!  Also, if it is not a Segwit transaction, then before confirmation there is the tx malleability issue to worry about.  Segwit fixes tx malleability.

Run a full node for validation, too.  SPV and other “light” clients can be fooled by certain attacks.  I don’t think an SPV node could be made to accept a “fake” transaction, in and of itself; but it could be misled onto a forkchain, which would allow feeding it a whole ledger full of fake transactions.

As illustrated above, you are replying to somebody who misapplied the fungibility issue to FUD Segwit.  That’s a totally nonsensical non sequitur, like saying that gold will crash because I have a headache.  (It is true that I currently have a headache, brought on by too much FUD.)  Segwit transactions are equally secure as to old-style transactions—actually, before confirmation, more secure due to Segwit’s tx malleability bugfix.  The only people ascribing “taint” to Segwit transactions are BCH shills, most of whom don’t own any Bitcoin anyway.

To describe the fungibility issue in itself, and answer your question:  You can create a new address for each transaction—you should do that; and it helps with, but does not solve the problem.  What is really needed is strong transaction unlinkability, so that nobody can consider a coin to have “taint” based on its prior history.  By analogy, consider a $100 bill being passed hand to hand:  Your bank can’t close your account and blacklist you if you deposit a $20 bill which, unbeknownst to you, passed through the hands of a drug dealer, who gambled it with a bookie, who used it to hire a plumber, who bought a widget from you.  Whereas some services such as Coinbase will do exactly that.  (Quick solution:  Don’t use Coinbase.)

Things like CoinJoin reduce the problem, by introducing confusion about which coins passed through whose hands.  Confidential Transactions will really help.  A sidechain with zerocoins would be great for fungibility.  I also expect Lightning Network to substantially increase fungibility:  On Lightning, coins will rapidly pass through many different hands without ever leaving a mark on the blockchain; on a mass scale, this will break up the transactional links which some people use to “taint” coins.  N.b. that Lightning is enabled by Segwit, depends on Segwit, and cannot be implemented by any forkcoin which lacks Segwit.  CoinJoin will also get a big boost from Schnorr signatures, an upcoming technology which will be implemented via—you guessed it, Segwit!

Thus as you can see, the lying little insect self-identified as “realr0ach” was building a pernicious half-truth out of a problem which is real, but here irrelevant.  Nobody is tainting Segwit coins.  Nobody has any reason to, except for Roger, Jihan, and their idiotic sycophants.

Disclosure of interests:  I am a privacy activist, and I lost a painful amount of money on a perfectly unlinkable, thus fungible altcoin; I can’t very well be accused of not caring about fungibility.

From the ground up!?  You will not get any competent developer to implement Bitcoin from scratch for you, for even ten times the quoted amount.  What’s next, asking for an operating system kernel “from the ground up”?  For under $10k, depending on requirements, you may get a competent developer to build something neatly customized for client needs on top of Bitcoin Core.

Open source software doesn’t “get hacked easier” by virtue of being open source.  The biggest websites and services on the Internet run on fully open-source stacks, from OS to applications.  As for Bitcoin, Bitcoin Core handles the exchange-value equivalent of hundreds of billions of dollars worldwide.  Its developers take security seriously.  For those with either their own expertise, or with very high value to protect (and a commensurate security budget), the Core developers were some of the pioneers in reproducibile builds of binaries to enhance professional security auditing.

A developer who builds a custom solution on Bitcoin Core can implement features such as signing high-value transactions across an airgap, while keeping smaller amounts in the online “hot wallet”.  Also of course, a customized interface and/or integration with existing business software.

If security and mission-critical reliability are important to your client, I would not recommend anything other than Core.  It’s not only a matter of protecting from intrusion:  Running a Core full node provides full validation, which protects against various network attacks which can fool SPV or other “light” clients.  It also enhances privacy (thus, confidentiality of potentially proprietary business transactions).  I would not run a Bitcoin business on anything less than a full node.

Username checks out.

---

I quoted at length, to illustrate a point:  The truthfully named “realr0ach” is using textbook smear tactics, combining imaginary problems with real-but-irrelevant problems in an ever-shifting argument.  You properly answered the nonsense about “anyone-can-spend”; so realr0ach ignored what you said, and moved the goalposts (plus made a bizarre, groundless accusation about “your stance”).  As such, trying to squash realr0ach’s arguments will be like trying to exterminate real roaches by squishing them one at a time.

Of course, Bitcoin fungibility is a problem (with various ad hoc, but sometimes fun and creative fixes).  And of course, Bitcoin fungibility is not decreased in any way whatsoever by Segwit.  Actually, by introducing the script version system, Segwit opens the way for new features (such as Schnorr signatures) which will assist or enhance fungibility solutions.

Meanwhile, you’re arguing with a self-identified disgusting insect.  Squish.

Interesting.  Using an isolated agent (such as gpg-agent) for Bitcoin signing would be a generally excellent idea, of course.

From your first link:


Right.  Though I make moderate use of some “pure Python” Bitcoin stuff, in the back of my mind, I always have the same worry.  IMO, crypto algorithms should be done reasonably “close to the metal”.  Does the Python interpreter have any behavior which opens side channels?  And in a related matter, don’t get me started on all the advice to “download bitaddress.org and burn it into a CD”, or the like.  Forget algorithm implementation side channels:  In Javascriptland, whence comes its randomness?  I peeked, and it’s not a pretty sight!

I do want to get Core’s secp256k1 running on all my systems.  Despite being plastered with warnings, “work in progress... research... Use at your own risk,” I trust it more (or distrust it less) than the vast heaps of junk out there.  I definitely trust it more than OpenSSL.  It was designed specifically for safety (as well as performance), “structured to facilitate review and analysis”, and made with an explicit design goal, “‘Be difficult to use insecurely.’”  I know the difference between a programmer and a cryptographer; and I am a programmer.  secp256k1 is exactly the kind of library I want.  I don’t want any coins lost to accident or malice!

There is also the matter of programming sanity.  Using OpenSSL, I don’t even know which context objects (if any) can be safely reused, and/or shared between threads.  The manpages do not mention such trifling concerns.  Core’s secp256k1 gives explicit instructions about this in the reasonably concise, copiously commented header which currently seems to serve as its documentation.  For my little “toy”, I am only generating keys; so I can initialize a context once, then reuse it a few billion times without reinitialization.

Core secp256k1’s README says, “Intended to be portable to any system with a C89 compiler and uint64_t support.”  Excellent!  I’ve poked around in the code; and I think the Autohell build requirement could be excised with relative ease.  But for the same aforestated reason, this is just not something I want to mess with.  (libbase58 is a different matter, plus a few orders of magnitude smaller and simpler; I should poke at it later.)

BIP 16 was an evil attempt to subvert the blockchain.  All versions of Core have been corrupted since version 0.6.  Now, I made my own fork of the Bitcoin with Satoshi’s original vision.  No P2SH!  To disinfect the chain, I helpfully added a transaction which spends to me all “anyone-can-spend” P2SH outputs since P2SH activation on 2012-02-15, Block #105571.

Also, to scale up and stop ripping off users with fees, I increased the blocksize to 32MB and decreased the block generation target to 30 seconds.  That scales up to 640x the tps of Blockstream bitcoin.  To avoid exploding UTXO growth and solve the problem of lost/burned coins, I added a consensus rule of coin aging; it consolidates all outputs more than 1 year old, and sends them to me for safekeeping.  This will be the fastest, cheapest Bitcoin ever.

Anybody want to join my chain?  Soon, I will post my fork code (it is taking awhile to make this, since I fired Core).  Download that, and connect to 198.51.100.127:8333 or dw7xvnkm4qsv5ikz.onion:8333.  Soon, we will kill off the legacy chain of P2SH-infected Blockstream bitcoin which is non-fungible and has cooties.  All will be flippening over to this chain.  I call my fork.lol Bitcoin Pyrite.

---

P.S., thanks, pebwindkraft.  I didn’t reply to you before, because I thought you’re probably right.  Sorry to seem rude.  Too bad SMF has no “like” button.

casascius, I wrote my below conclusion before I stepped away for awhile (and gmaxwell showed up).  I didn’t post it, because I wanted to first cook up a vanity address to add some “wow”; unfortunately that’s not done, per below.  But I’m glad to see that things seem to be coming together here.

gmaxwell, sorry, I should have made clear that I’ve read BIP 173 and assumed familiarity therewith.  Otherwise, I would have mentioned the NIST data, instead of obliquely referring to “the research it cites”.  I do appreciate your explanations of the Bech32 rationales, with tantalizing hints of what went on behind the scenes of that production.  Also I hope you caught my sarcasm, which can oft be dry as liquid helium; of course I’m not seriously complaining about the look-up table!

I suggest that perhaps, you should perhaps list to your rationales that Bech32 addresses can be read off efficiently and unambiguously with with standard radio alphabets.  In similar circumstances, I find this can be indispensable for communicating over the phone.  The version zero witness for my money is Bravo Charlie One Quebec...  It may also be wise to rebrand them with a nickname as Bravo Charlie One Addresses (or simply “Bravo Charlie Addresses”, to avoid confusion with version zero so-called “1-addresses”; the word triplet also sounds snappier).

---

Unfortunately, I stepped out of the discussion just when it picked up.  Real life seized me away, after my attempt to find something suitably impressive for casascius hit an unfortunate snag of GNU Autohell; but I now have an airgapped CPU grinding away.  The following are just some quick tests.  Nested P2WPKH-in-P2SH and Bech32, a direct comparison:  Ain’t Bech32 pretty?


N.b. that I am in general leery of vanity addresses.  They do restrict the keyspace, at least theoretically; and by grabbing human focus with a false impression of readability, they’re tantamount to an invitation to spoofing.  But being flesh and blood, I also understand the attraction (and the marketing angle).  I also realize that due to the error correction, Bech32 strings don’t have the same uniform distribution properties as the old addresses (gmaxwell, please correct me if I’m wrong there!); from this perspective, I think that’s actually a benefit.

Also, ever since this discussion started, the idea of writing Bech32 in uppercase has been growing on me.  Directly compared, which looks better to you, casascius?  For that matter, which would be more pleasing when engraved in shiny metal?

---

Actually, I didn’t know what you meant beyond your words; and I’ve spent so much time lately shooting down the “still stuck with 1MB blocks” myth on this forum that I keep that code snippet (plus a formatted piece of BIP 141) ready for copypaste.

I think the biggest help for users right now is to get them using Segwit addresses.  I’ve been trying.  I’ve been handing out explanations of how to generate backward-compatible P2SH-nested addresses on the m/49'/0'/0' derivation path with Electrum 3 (so as to actually receive money while people slowly upgrade), launching my flamethrower at anti-Segwit agitprop and FUD which is so stupid that it would be comical if it weren’t so disgusting, and above all:  Shouting at the top of my lungs about how people can discount their own fees right now by using Segwit addresses.

All those people crying to you about fees—do their addresses start with a “1”?

You’re passionate about Bitcoin, casascius, and you’re passionate about users.  For the individual, so much of the current fee pain can be assuaged immediately by simply moving away from “1-addresses”—and when everybody gets onboard, the whole network will benefit as the effectual block capacity grows to Segwit’s potential.  Bitcoin is always that way:  Aligning the common good with the selfish interest of each individual, so that the latter pushes the former.  People still using 1-addresses are hurting the network; and in paying higher fees, they are suffering the natural consequences of their disproportionate capacity impact on the community.  If your transactions weigh more, byte for byte, then you pay for it!  I suggest that pushing Segwit adoption would be a good means to act on your desire to engage and help people who are struggling with fees, and also to do good for the health of the network.

---

Damn straight.  (Your sig, too.)

Satoshi’s Bitcoin was real run-and-gun cypherpunk code.  AFAIK, the initial versions were not even portable between platforms.  “Cypherpunks write code”; and the important part is that he encapsulated his brilliant idea in a functioning public alpha about two months after announcing his paper.  Talk is cheap; action can change the world.

Of course that was not the end, but only the beginning.  Satoshi jump-started the movement of cryptography-based digital currency after the very idea had been then moribund for a decade—conference talks and idle dreams notwithstanding.  And he did more:  Whether or not foresaw his own results, he created ex nihilo a social organism of a kind which has never before existed.

One of my own secret dreams is to hack up some code implementing a brilliant idea no one else had, then let people such as gmaxwell and sipa pour “a lot of testing with both people and machines, several CPU decades” into some small area where I personally happen to lack perfectly omniscient expertise.  For now, I can keep dreaming.

---

Well, enjoy your Bitcoin Porsche and a small slice of cake.  We’re in for a wild ride—but when has it not been?  Someday, a few old men will look back on the Coin Wars back around ’15–18.  I’m not overconfident of what they’ll remember; but I am confident, nevertheless.

I happen to like Core, but they are not Bitcoin.  They provide only the necessary prerequisite:  Reliable software which can keep safe the exchange value equivalent of hundreds of billions of dollars in value throughout the Bitcoin ecosystem.  Beyond that, you ought know as well as anybody that code alone can’t solve people problems.

Bitcoin is a sociological phenomenon.  Now we see the latest battle in an ongoing political war.  What fights for Bitcoin is—Bitcoin.  The thing is running headless, just as it’s supposed to do.  Bitcoinum nullius est.  It’s a decentralized social organism which belongs to nobody, with nobody in control.  It derives its value from its nature as such.  It fends off enemies by the power of multitudes who believe in it—and the many who have much to lose—many of whom are otherwise enemies with each other; all of whom agree on only one thing, Bitcoin.  Core (as L. cor) could stop the heart of Bitcoin by caving in, or ceasing technological improvements.  But this is beyond Core, you, me, or anybody else involved.

For Bitcoin owns; it is not owned.  I don’t mean the monetary component, in the sense of people who are owned by their wealth.  I refer to the sociological phenomenon.  Bitcoin owns.  You know what I mean.  Each and all of you know exactly what I mean.

You do know that this has been considered before, and you are aware of “significant downsides”, due to the discussion which ensued when you asked this a few days ago (q.v.):


For my part, I like how gmaxwell addresses this (bold/large text in the original) (permalink):


Good point about the “weird incentives”.  Also, the “ATTENTION” part.

Following all the recent discussion about Segwit and Bech32, I felt the urge to have some fun.  I happily put together Core’s  secp256k1 and luke-jr’s libbase58 (plus sipa’s reference bech32) to whip up a trivial Segwit bulk address generator—which of course, just had to grow a simple regex bruteforce vanity function:


Pleased with my new toy, I grabbed my little C file plus its few dependencies, and catapaulted them to an airgap Unix machine.  It would be so nice to let it grind away on some spiffy long-term tip addresses.

No, wait:  secp256k1 and libbase58 both use autoreconf in their build systems.  Sigh.  Download GNU autoconf and its signature, load ’em into the catapault, and let fly across the airgap.  ./configure.  Easy, right?


Sigh.  So much for a way to relax and unwind.  My system has an M4, but not GNU M4.  More downloading.  Ready the catapault again.  It is running out of fuel—actually, it’s not a catapault:  It’s a magnetic railgun.  I take my airgap seriously.


At this point, I gave up and hacked together some ersatz—with OpenSSL’s[1] libcrypto, for secp256k1 and bignums (base58).  Of course, I still want to use Core’s code on machines which have autoreconf.  Thus now, my neat little C file is a mess of #ifdefs—plus a few ad hoc extern declarations to another C file, where I put my OpenSSL glue and my quicky little base58check encoder.

Then, I wrote a set of automatic runtime self-tests to make sure this bucket of bolts gives exactly the same observable behavior in both configurations.

So—is there any reasonable way to get this stuff built without autoreconf?  It’s an absurdly horrid “portability” fix, if it gives your project a build-time dependency on GNU M4, Perl (!!!), and who knows what hundred other packages in the spiralling dependency chain.  This would be inconvenient in ordinary circumstances.  It can be much worse for software expected to be used in a security-critical context, implying an airgapped machine with the minimum possible junk installed on it.  Seriously—I use the kernel’s virtual terminals there, because I reasonably distrust Xorg, window managers, toolkit libraries....  I was exaggerating about the railgun; I am not exaggerating about shell job control and my trusty old nvi.

Thanks for any reasonable[2] suggestions.

---

1. Yes, I know that OpenSSL’s build system directly uses Perl.  My platform’s distributor runs all that Perl stuff as a sort of preprocessing step, and imports the results into a vendor directory in the source tree.  It is unfortunate that that piece of bugware because such a ubiquitous dependency, though this is slowly changing.

2. Please, nobody say “just use Linux”.  That would sound exactly to me as “just use Microsoft” would sound to you.

Uh-huh.  Okay, I got it now—loud and clear.

Myself, I would “applaud” having free chocolate cake and a Porsche.  But there is a word for people who expect to consume precious resources without somehow paying for them.  The word is not “neurotypical”; the word is “retarded”.

Byzantine fault-tolerance is costly, and proportionately so as to the actual usage of the network.  Therefore, amongst “cryptocurrencies” thus far, the choices are these:  (0) Centralized, popular, and cheap.  (1) Decentralized, unpopular, and cheap.  (2) Decentralized, popular, and expensive.  Those, plus all similar variations except for decentralized, popular, and cheap.

Thus far, all Bitcoin competitors with low fees have either a relatively much lower demand for transactions (unpopular), actual or potential centralization, or both.  Bitcoin also had low fees when it was unpopular.  After Bitcoin beats down a few more attempts at centralizing hostile takeover (as it did last month, too), Lightning will see Bitcoin lead the way, yet again; but meanwhile, loudly wishing for “decentralized, popular, cheap” on-chain does no more good than my sincere wishes for a Porsche.  Right now.  I want, gimme!  The address is in my signature.

But surely, the average deadweight mass of gelded cud-chewers don’t much care about decentralization.  They’ll take Visa Platinum, Mastercard Platinum, or “Bitcoin Platinum With Ponies”; and it’s all the same to them.  They’ll also use Google and Facebook without a second thought, no matter how much you scream at them, “You are the product.”  They give never a thought to Cloudflare.  They want their dancing pigs; and they want that fast and cheap, the latter only being evaluated through the myopia which sees no hidden costs.  Insofar as I must deal with that type, the blissful slave, my objective is not to cater to them, but to persuade, cajole, or shock-prod them where I need them to go.

But of course, you’re not exactly new around here.  You knew all the foregoing—except perhaps that last, which is personal as to me.  For my part, I suppose that I learn something new every day.

As for this:


FYI, Bitcoin no longer has 1MB blocks:


HTH; after all, it’s still the Technical forum, no matter how much junk I trip over here nowadays.

No, I think the most likely targets are sites such as bitcointalk.org—see below.  Plus the six million other sites which Cloudflare claims as customers.  Plus sites which have been censored off the Internet by DDoS.  And here, you want to (further) commercialize DDoS—so that anybody with deep pockets (or Deep State connections) can more easily buy censorship on demand.  Sounds like fun!

Do you really think that a big bank has a problem shielding its network behind another huge corporation’s anti-DDoS network?  This isn’t 2011 anymore.  They’re wise to this stuff.  Yet the more you monetize DDoS, the more likely a big bank will secretly buy some extra DDoS against its most hated competitor, bitcointalk.org.


No.  My read is that either you’re an undercover agent, or you’re a patsy sleeping on the floor next to the foot of the bed of the “omnipotent security apparatus” while you delude yourself that you’re fighting it.

I’m not bothering with your video right now.  It’s too cumbersome with my high-security Tor setup.

P.S., I forgot:


What the hell are you talking about?  Bitcoin isn’t illegal.  Unfortunately, neither is the absurdist centralized exploding clown car known as Ethereum—the coin which can’t keep its promises that code is law.

In Bitcoin, there is no such thing as a “from” address.  Any system based on such a design will drop money on the floor.

What you need is a forthcoming new feature:  Schnorr signatures.  This will allow one signature to cover all your inputs:


It will also improve privacy, which I think is certainly a concern when inevitably coin-merging all your customers’ payments.

Unfortunately, it’s not here yet.  Meanwhile, yes, fees are quite problematic for your use case.  I hope that at least you’re using Segwit addresses like the one in my signature; if you’re not, then each of those extra public keys and signatures in your spends is quadruple-weighted in the fees you need to pay.  For a typical consumer transaction, that’s a big waste; for your use case, the difference will be obscene.  Signatures and public keys are relatively large, in measure of bytes; and when you are spending the proceeds from many receiving addresses, of course, you need one of each.

---

This makes no sense whatsoever.  The standard industry “best practice” recommendation is to use one receiving address for each transaction.  You’re spouting nonsense.