[HN Gopher] Hal Finney's Proposal for Optimizing Bitcoin to Be E...
___________________________________________________________________
Hal Finney's Proposal for Optimizing Bitcoin to Be Enabled in
Bitcoin Core
Author : syck
Score : 89 points
Date : 2020-09-27 10:14 UTC (5 hours ago)
(HTM) web link (www.btctimes.com)
(TXT) w3m dump (www.btctimes.com)
| trident1000 wrote:
| Why was a patent even respected with a decentralized system that
| doesnt even have cash flow/profits?
| gruez wrote:
| Because businesses use the software as well? If you want to
| promote the usage of bitcoin, the last thing you want to do is
| scare away businesses from using your software.
| CydeWeys wrote:
| Because violating it would nevertheless cause very real
| problems for the developers, businesses, and perhaps even users
| with public identities living in jurisdictions that might come
| after them for it?
| Taek wrote:
| Many of the core developers live in the US jurisdiction under a
| public identity. Many of the major corporations in the space
| such as BitGo and Coinbase also are in the US jurisdiction.
|
| If everyone is anonymous, you can probably ignore the patent.
| But if you want legitimate businesses to be able to use the
| software, you need to respect the laws in which those
| businesses operate.
| trident1000 wrote:
| Yeah that makes sense. Better to play by the rules even
| though they could so easily just push it through anonymously
| and there's nothing anyone could do about it. But its better
| for the image of Bitcoin and of course the known teams behind
| the updates.
| skee0083 wrote:
| Who cares. Bitcoin is a joke. All PoW based coins are a joke.
| They can't scale to meet transaction demand and once the rewards
| run dry there will be no incentive left to mine them anyway. CBDC
| is the future like it or not.
| SRTP wrote:
| Imagine having such a minimal understanding of Bitcoin yet
| feeling entitled to post your inconsequential opinion online.
| tromp wrote:
| They can't scale to replace fiat, but they can scale a lot more
| with off-chain (so called 2nd layer) solutions.
|
| Not all PoW based coins have rewards going to zero; some have
| so called tail rewards and others even have constant reward
| like 1 coin per second forever.
| skee0083 wrote:
| Literally no one uses lightning network.
| SRTP wrote:
| False. Tons of people do.
|
| Post an invoice of 1,000 sats here and I'll send some Sats
| your way.
| fiach_dubh wrote:
| I do, if anyone wants a 100 satoshis just paste your
| lightning invoice request below as a comment and I'll pay
| it you 100 satoshis. (download the wallet of satoshi app)
| dsmurrell wrote:
| I like to use Bitcoin as cash. Bitcoin Cash. BCH. BTC has been
| stifled at the base layer so that the devs can make money off
| layers on top of the base layer.
| tromp wrote:
| As Hal explains in his post [1], this let's you replace a general
| 256-bit-scalar x curve-point multiplication k x Q by
|
| (k1 + k2 x lambda) x Q = k1 x Q + k2 x (lambda x Q)
|
| where k = k1 + k2 x lambda mod n, k1 and k2 are only 128-bit, and
| lambda has the special property that for some beta, lambda x Q =
| (beta x Qx mod p, Qy), i.e. at the cost of just a scalar
| multiplication, yielding a 25% speedup.
|
| [1]
| https://bitcointalk.org/index.php?topic=3238.msg45565#msg455...
| tromp wrote:
| Apologies for the use of 'x' to denote multiplication. I just
| figured out that I could have written as asterisk __* as 3
| asterisks in markdown, but it 's too late to edit my post now.
| FrendlyReminder wrote:
| Finney was a wonderful man. He was there with PGP from the start.
| The last few years of his life he suffered tremendously. When the
| world started finger-pointing him as Satoshi his family got
| death/kidnap threats, swatting and worse.
|
| Hopefully anyone with the time to care about this will read one
| of his last comments on the subject dictated through eye-movement
| software from a wheelchair:
|
| https://bitcointalk.org/index.php?topic=155054.0
|
| Vale Hal.
| grahoho wrote:
| Also why some other folks suspected of being Satoshi have
| denied it so arduously.
|
| If the above poster is Satoshi (which I suspect, it being a new
| account), I'd like to thank you for your contribution. Your
| writings are underrated but will be appreciated by future
| economists, developers, and historians.
| [deleted]
| techbubble wrote:
| Hal's post was so inspiring - thank you for sharing.
|
| The bit about having to finish the documentation was
| particularly noteworthy. Even when writing code laboriously
| through eye moment, Hal didn't lose focus of the importance of
| documentation.
| seibelj wrote:
| Hal is the person I believe was Satoshi. All of the evidence
| points to him more than anyone else I have read about. But
| wanting to keep his identity secret makes perfect sense given
| what happened.
| FrendlyReminder wrote:
| I don't believe it at all and there's plenty of evidence to
| the contrary that people can find for themselves.
|
| That's my honest opinion and you are entitled to yours,
| fairly sure no one will ever know for certain. There's a
| journalist that went deep diving on this and came out with
| the same conclusion, from timelines to stylometric analysis,
| it doesn't add up to being Hal. He's just that guy who
| actually listened on the mailing list rather than be the
| snarky one where everyone else nods in agreement
| congratulating themselves how smart they are.
|
| In the last years of his abled life, the man was getting
| involved in whatever cutting edge technology he could find,
| most of this is documented, nearly all of them failed, except
| for twitter and bitcoin. He's now cryopreserved, something
| that has virtually no chance of ever succeeding in the next
| 1000 years, yet...
| seibelj wrote:
| The fact he lived very close to Dorian Satoshi Nakamoto (2
| blocks away) is the most damning evidence to me. Explains
| why he selected that name - he thought it was a good name
| and he noticed it! Secondly him being the first person to
| respond to Satoshi is highly suspect to me, he could have
| been responding to himself.
| CydeWeys wrote:
| Huh, that's an interesting fact! I wonder what percentage
| of people outside of Japan live that close to someone
| named Satoshi Nakamoto?
| nobrains wrote:
| My guesstimate is Nick Szabo.
| bhaak wrote:
| If you look at Szabo's twitter feed these days, I surely
| hope he isn't.
|
| Luckily, there is not that much that points towards him
| being Satoshi:
|
| https://archive.is/N3rYx
|
| https://davidgerard.co.uk/blockchain/2018/12/16/no-nick-
| szab...
| svd4anything wrote:
| His twitter feed is very libertarian and Austrian
| economics themed. That doesn't surprise me at all, should
| it?
| CydeWeys wrote:
| He says he hopes it isn't him, not that it lends evidence
| against it.
| svd4anything wrote:
| I understand but that's a strange hope a bit based on his
| twitter bring too right-wing or libertarian than he would
| prefer, yet those beliefs are actually very consistent
| with a lot of Satoshi's known leanings and beliefs. The
| block zero comment is pretty libertarian for example and
| many of his comments on email lists are also. So it's a
| bit illogical for the OP to hope for otherwise.
| mhluongo wrote:
| I'm a libertarian Bitcoiner myself, and I hope it's not
| Szabo.
|
| You can be right libertarian without being a xenophobe or
| an outright racist.
| seibelj wrote:
| Expecting Satoshi not to be libertarian is like expecting
| Karl Marx not to be socialist. Satoshi devoted his life
| to creating uncensorable money outside of government
| control!
| nix23 wrote:
| >Karl Marx not to be socialist
|
| He was not a socialist, he was a Marxist. It's like
| expecting that Windows and Linux are Operating-systems
| and by that completely the same.
| tim333 wrote:
| Dunno about virtually no chance - we just need exponential
| improvements in scanning and computing to go on a while
| longer.
| akritrime wrote:
| A bit tangential but I have a question. This is one thing that I
| don't really understand about bitcoin, how open is it, to be
| declared free from government influence? The power of the core
| technology still resides with who ever has the key to push
| changes, and there lies a lot of vested interest. Like an
| external agent can still influence the devs who are making the
| changes and then majority of the nodes to accept that change. Its
| not really resilient to outside forces, right? Or am I missing
| something?
| skizm wrote:
| I would think, given how popular bitcoin is, every single
| change that goes into the code is reviewed by hundreds or
| thousands of developers. Malicious code will most likely be
| caught, and then someone can just fork it at that point and
| everyone who cares about their BTC investment will switch over
| to the new chain.
| Taek wrote:
| Bitcoin is set up such that there is no auto-updating feature.
| Any change to Bitcoin must be accepted manually by all
| participants.
|
| But there's still a question of "how many people actually
| review the changelog before updating?" It's a very small
| number, but that might be okay. If a bad actor pushes malicious
| code through, all you need is one person to raise the alarm.
|
| In general, Bitcoin is very well reviewed. I don't think it
| would be easy for a bad actor (even a good actor who is being
| compelled in secret by a state actor) to push through malicious
| code. But it's hard to be certain exactly how robust Bitcoin is
| to this type of thing.
|
| The culture of Bitcoin is highly resistant to changes in the
| core code. Even optimizations are increasingly scrutinized.
| Attempts to influence the core devs ("psyops") are also likely
| to fall flat, simply because the core devs have gone to great
| lengths to ensure that there is a lot of red tape to making
| changes, and that larger changes take years to get through with
| hundreds of eyes of review.
| hudon wrote:
| The fact that changes to Bitcoin Core get some amount of
| reviews is not enough for all vulnerabilities to get caught,
| as seen here: https://en.bitcoin.it/wiki/Common_Vulnerabiliti
| es_and_Exposu...
|
| And some of those vulnerabilities may have been planted
| intentionally, we'd never know.
| Taek wrote:
| A lot of the CVE's there are pretty minor. There hasn't
| been a serious but in Bitcoin core that I know of since
| 2018, and the one before that was in 2016.
|
| Not perfect, but overall I think that's a pretty decent
| track record.
| dfischer wrote:
| That misses the point entirely that most people that actually
| use bitcoin don't even use bitcoin core's wallet. They use
| other wallets and trust that software and the hardware they
| are on to be doing the right thing. The average person not
| only does not understand this distinction, they don't even
| know how to validate their own transactions let alone know
| how to read code.
| dannyw wrote:
| There are multiple competing full clients.
| theelous3 wrote:
| Pushing code to a repo doesn't mean it's used in prod. It's
| vulnerable to takeover by a massive single group (though v
| unlikely and this would ruin the value), or small co-op of the
| largest miners, but it's vulnerable to that in every sense.
|
| So it doesn't really matter who can push code to what repo. It
| only matters who can organise the majority of computational
| power.
|
| I'm not saying it's _not_ vulnerable, but I am saying that
| investing in taking over btc in order to enrich yourself will
| by its nature backfire, and that it 's not really vulnerable to
| code change in any way like a centralised system.
| gruez wrote:
| >So it doesn't really matter who can push code to what repo.
| It only matters who can organise the majority of
| computational power.
|
| No, the economic majority[1] also matters. If the miners
| decided to hardfork bitcoin and double their mining rewards,
| and the non-mining users did not support this change, their
| fork would fail because nobody would accept their coins. This
| is exactly what happened to the segwit2x fork[2], which was
| arguably less contentious than doubling mining rewards.
|
| [1] https://en.bitcoin.it/wiki/Economic_majority
|
| [2] https://en.bitcoin.it/wiki/SegWit2x
| akritrime wrote:
| I guess the piece of the puzzle that I am missing is how does
| the change go from repo to prod. Do the miners need to pull
| the latest code from GitHub?
| hudon wrote:
| The truth now though is that those who can "organize the
| majority of the computational power" are the same as those
| who can push to Bitcoin Core. One must only look at recent
| forks to see how this power grab happened.
| saurik wrote:
| Systems are as decentralized as the people running it; if you
| convince by force the majority of the people running it to
| accept your change then I guess you win, right? FWIW; there is
| still the question of what the people who reject the change
| choose to do--give up or resist--and if they go with resist
| then they effectively become a fork of the network and now
| there are two networks: the one that was forced to accept your
| corruption and the one that didn't... since all the effort of
| the larger network you corrupted is busy the latter network
| could possibly still be secure. Really if you want to do that
| you don't want to push a band update you want to force people
| to counter the protocol: get a majority of then hash rate to
| promise to cause chain reorganizations constantly to screw with
| the smaller forks.
| wslh wrote:
| > Systems are as decentralized as the people running it;
|
| No, this is the worst case scenario, the core developers of a
| technology like Bitcoin have the power to, arbitrarily,
| govern the project and change the code or protocol without
| the people noticing or caring about it. There are obviously
| limits that are not acceptable to the people (e.g. SegWit2x
| and Bitcoin Cash). The governance of a protocol is mostly
| centralized. Perfectly decentralized systems are
| decentralized systems that never change. If they change it is
| because there is governance that plays in the power context.
| fartcannon wrote:
| There have been numerous forks. If someone attempt to force in
| code via intimidation or whatever, the chain can be forked from
| any block and started up again without that code by anyone.
| hudon wrote:
| You're right, the only thing preventing what you're saying is
| the community keeping the leaders in check. But the leaders
| have way more influence individually than each community member
| does, so if one with git access to the Core repo is compromised
| by the CIA let's say, they can nefariously push for changes
| that seem innocuous but actually benefit some entity with deep
| pockets. And most of the community doesn't review each line of
| code that gets changed.
| dfischer wrote:
| It's not resilient to outside forces. I would argue strongly
| that it's a huge risk to the majority of the population under
| the consideration of computation complexity.
|
| The computation stack end to end has alarming risks. If the
| average user can't read code, then anything they use is a form
| of delegated trust.
|
| The users trust the wallet software that it's doing the right
| thing. The average user does not even know what validation
| means.
|
| Additionally what is known about computation is public
| knowledge. What secrets exist within state actors or even
| possible ET tech that could be used to influence truth with
| advanced computation?
|
| There's certainly no guarantee of security within Bitcoin or
| the network. It shifts the trust model at the most.
|
| In another perspective, the amount of individuals who
| understand cryptography are quite low for the entire human
| population. Combine cryptography with hardware and software and
| that's the small percentage of people who truly "get it" and
| are also specifically the ones entrusted as the leaders of all.
| The attack vectors are large.
|
| In order to fix this we need to reduce complexity across the
| stack end to end. Every individual should know how to build
| their own computer without having to trust any hardware or
| software manufacturing.
|
| I'd argue the stack is needlessly complicated end to end.
| Individuals add complexity by allowing the conceptual model of
| computation to remain complex within their tooling and then
| adding their own esoteric layer on top. It's a house of cards.
|
| Here's a good post by Bruce Schneier
| https://www.schneier.com/blog/archives/2019/02/blockchain_an...
|
| Would I keep a significant portion of net worth in bitcoin? No.
|
| Would I use it to make a payment like PayPal? Yes.
|
| I do not trust anything with computation today. It is
| compromised end to end.
|
| As long as the Internet depends on BGP and ISP's there's no
| true decentralization. We need ad-hoc mesh networking with
| deterministic address spacing. Doing so behind some type of
| one-time cryptographic address that maps to an IP would be
| interesting. A few projects are experimenting in this path.
| Yggdrasil looks promising as an algorithm. Ouroborus has an
| interesting novel stack based on recursion.
|
| I mention all these things because it's exactly the reason why
| bitcoin is not safe or to be trusted. The cult behind it
| doesn't help the fact of the fragility of the situation. Much
| of the cult are increasing the risk of other individuals by
| preaching trustless models.
| paulryanrogers wrote:
| Can anyone speak to the possible energy savings this change may
| provide?
|
| Or is BTC too fundamentally tied to CPU-bound work?
| noxer wrote:
| Its irrelevant. Just like any other improvements made to BTC
| core. Its deprecated tech since years. We have DLT without PoW
| or PoS since like 2013 which should (in a rational world)
| render PoW/PoS solutions useless. But people hold on to old
| stuff especially if it made them rich or poor.
| pjc50 wrote:
| You can't save energy in bitcoin, because proof-of-waste is
| intrinsic to it's functioning and the difficulty adjusts to
| keep it that way.
| deevolution wrote:
| Bitcoin miners are utilizing excess energy that would
| otherwise have gone to waste. So there's nothing wasteful
| about it. In fact, miners must be as energy efficient as
| possible in order to remain competitive and profitable.
| Typically excess power is the cheapest source because there's
| no demand for it, hence why efficient miners use it. Check
| out great American mining[1] for example. They harvest wasted
| energy from gas flares to power bitcoin mining rigs.
|
| 1. https://gam.ai/
| lukeschlather wrote:
| Even with free electricity, the embodied energy of the
| computers used is basically wasted. A simple notary service
| that signed transactions with a timestamp and published a
| record to a public data storage bucket could handle
| worldwide bitcoin transaction volume running on a single
| machine, if you traded proof-of-waste for a simple root
| trust store.
|
| (I mean, if I wrote it it would probably take several
| hundred machines but I'm sure Satoshi or some other
| brilliant programmer could fit it on a single machine. It
| only processes what, 5 transactions per second? My first
| dumb cellphone might be able to do that many signatures per
| second if someone could figure out how to compile the
| relevant libraries to run on it.)
| RL_Quine wrote:
| ecdsa speed is related to client performance, it has nothing to
| do with the power consumption of proof of work.
| r1ch wrote:
| This only helps nodes verify blocks, the mining is what uses
| huge amounts of power and that won't change.
| comboy wrote:
| Note that this is not mining, just running a full node. When
| running one, signature verification is most of what your CPU is
| doing.
| ucha wrote:
| There will be energy savings for the nodes that have a copy of
| the blockchain and need to verify transactions but not for the
| miners.
|
| Market forces fundamentally tie the energy consumption of the
| miners to the price of bitcoin.
| shp0ngle wrote:
| This is not relevant to bitcoin mining. Just synchronization.
|
| The mining is no longer (for 7 years or so) done by traditional
| CPUs. People use ASICs
| Ihfhcub wrote:
| Bitcoin miners are the ones that use the energy calculating the
| SHA256 functional. The cost of the function is not relevant to
| energy use as competition between miners means the energy used
| will match the value of the block reward.
|
| This optimizing is for the users of the bitcoin network that
| must validate that the rules are being followed so they can
| reject any miners that do not follow the consensus rules
| godelzilla wrote:
| That's ten+ years of wasted resources due to "intellectual
| property". Imagine the total global losses due to this coercive
| construct.
| MichaelZuo wrote:
| It's interesting that they were keeping the change in reserve for
| expiration day. I wonder what else is being kept in reserve that
| could enhance bitcoin?
| noxer wrote:
| >...that could enhance bitcoin
|
| It does not its irrelevant it chances nothing about bitcoin or
| its limits. Its a client side it does not speed up usage or
| something the CPU just useless less cycles and idles more.
| RL_Quine wrote:
| It reduces synchronization time substantially, as it involves
| literally billions of signature verification operations.
| noxer wrote:
| So what? It changes nothing at all. Block time/confirmation
| time is still the same/fees still explode if transaction
| reach the limit. Its completely irrelevant from a user PoV.
| RL_Quine wrote:
| Users still need to be able to verify data independently.
| nnx wrote:
| Schnorr signatures were also kept in reserve for many years due
| to a patent that recently expired. Should be merged in the next
| major feature release.
| RL_Quine wrote:
| Schnorr signatures are sort of a challenge to use,
| unfortunately.
| hanniabu wrote:
| As someone familiar with bitcoin but not cryptography, in
| what sense is it more challenging to use?
| RL_Quine wrote:
| Schnorr is most useful when used as a multi party
| signature. It works how you would expect it to, you can
| literally take a bunch of people signing the same message
| and end up with a single signature at the end by adding
| them all together. However this is annoying to do in
| practice because it requires back and forth communication
| between every party to produce the signature, which
| precludes its use in something like a hardware wallet
| where a user manually confirms a signature, as they'd
| have to do it many times.
| trident1000 wrote:
| I wonder if this is something a hardware wallet provider
| could solve on their end in the software. Like one
| signature is a go for subsequent needed signatures as
| long as nothing changes with the transaction or something
| like that.
| RL_Quine wrote:
| Possibly, it still has the expectation that all parties
| are online to some degree which isn't something we have
| in Bitcoin today, where signatures can be added even
| years after the fact when needed. None of this is killer
| or a reason to not use Schnorr, it's just not quite as
| much of a magic bullet as people originally expected. To
| my knowledge this wasn't a very well known property until
| anybody had implemented it for bitcoin, I doubt it was
| ever used once it was patented.
| trident1000 wrote:
| "where signatures can be added even years after the fact
| when needed"
|
| Why would you need this to be the case? In my mind (im
| not an expert) I just imagine schnorrs batching
| signatures into one tx on the chain. And then its done.
| Why would you need to add years after?
| RL_Quine wrote:
| Signature aggregation would be only on a transaction
| level, not on a block level as you require interaction
| between all signing parties, and any party can block the
| signature. You would also have to have some system of
| making a block, then everybody re-signing their
| transactions to make the block aggregated- it's just not
| happening.
|
| In Bitcoin today we can do things like make a conditional
| signature in a multi signature. With three parties, one
| can pre-sign a transaction and lock it until a future
| date, then hand it to the other parties who can sign it
| at their leisure when that time is elapsed. This would
| not be possible with schnorr unless you also had the
| expectation that all parties would be online when the
| lock time expires.
| nemo1618 wrote:
| I'll let Pieter Wuille explain: https://twitter.com/pwuil
| le/status/1297630790713348096?s=19
| angel_j wrote:
| I wonder many miners have already been using this optimization
| for the advantage.
___________________________________________________________________
(page generated 2020-09-27 16:00 UTC)