<unnamed>

Public Key

npub1tu9fzufm77cw438n470j5ac5myt3dzhyfw34pvdetsw5kvkrec6snelxvq

Profile Code

nprofile1qqs97z53wyal0v82cne6l8e2wu2dj9ck3tjyhg6skxu4c82txtpuudgpzpmhxue69uhkummnw3ezuamfdejsm9gr58

Publishing to

nostr.wine

Last Notes

2023-06-07 19:56:42 CEST

- reply

📅 Original date posted:2017-02-27
📝 Original message:Hi all,
I did not follow the whole discussion, but wanted to throw in some
literature on the failure of crypto primitives in Bitcoin.
There is a paper which discusses the problems, but does not give any
remedies: https://eprint.iacr.org/2016/167.pdf
And there are also contingency plans on the wiki:
https://en.bitcoin.it/wiki/Contingency_plans These are not very
detailed and my impression is that this information should be viewed
very critically (E.g., when ECDSA is broken, the suggested vague
response is "Switch to the stronger algorithm." Yeah. And "Code for
all of this should be prepared." Surely. As far as I know, there is no
such code and no-one is working on it).
Best,
Henning
On Sat, Feb 25, 2017 at 09:45:36AM -0800, Shin'ichiro Matsuo via bitcoin-dev wrote:
> We should distinguish collision resistance from 2nd pre-image resistance, in general.
>
> As previously written, we should care both hash output length and algorithm itself. The weakness of SHA-0 (preliminary version of SHA-1) was reported in 2004, then many research on the structure of SHA-1 were conducted. In the case of SHA-2, it is harder than SHA-1 to find collisions.
>
> Existing security consideration and evaluation criteria were extensively discussed in the NIST SHA-3 competition. Please see the following sites.
>
> https://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
> https://ehash.iaik.tugraz.at/wiki/Cryptanalysis_Categories
>
> We need similar analysis on RIPEMD160 and impacts of attacks on (RIPEMD160(SHA2(msg)).
>
> We can also refer the security assumption of hash chain in Asiacrypt 2004 Paper.
> https://home.cyber.ee/~ahtbu/timestampsec.pdf
>
> In the discussion of SHA3 competition, we choose another hash design structure, so called "sponge structure." This leads diversity of design principles of hash function and gives resilience even when one hash design structure becomes vulnerable. As Peter Todd wrote, discussion on design structure and algorithm is important. Discussions on all of algorithm, output length and security requirements are needed.
>
> At some future moment, we should think about transition of underlying hash functions. I’m working on this subject and will present an idea at IEEE S&B.
>
> Shin’ichiro Matsuo
>
>
> > On Feb 25, 2017, at 8:10 AM, Ethan Heilman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > >SHA1 is insecure because the SHA1 algorithm is insecure, not because 160bits isn't enough.
> >
> > I would argue that 160-bits isn't enough for collision resistance. Assuming RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions can be generated in 2^80 queries (actually detecting these collisions requires some time-memory additional trade-offs). The Bitcoin network at the current hash rate performs roughly SHA-256 ~2^78 queries a day or 2^80 queries every four days. Without any break in RIPEMD-160(SHA-256(msg)) the US could build an ASIC datacenter and produce RIPEMD-160 collisions for a fraction of its yearly cryptologic budget.
> >
> > The impact of collisions in RIPEMD-160(SHA-256(msg)) according to "On Bitcoin Security in the Presence of Broken Crypto Primitives"(https://eprint.iacr.org/2016/167.pdf):
> >
> > >Collisions are similar, though in this case both public keys are under the adversary’s control, and again the adversary does not have access to the private keys. In both scenarios, there is a question of nonrepudiation external to the protocol itself: by presenting a second pre-image of a key used to sign a transaction, a user/adversary can claim that his coins were stolen.
> >
> > How would such an event effect the price of Bitcoin when headlines are "Bitcoin's Cryptography Broken"? How much money could someone make by playing the market in this way?
> >
> > For both reasons of credibility and good engineering (safety margins) Bitcoin should strive to always use cryptography which is beyond reproach.
> >
> >
> > On Sat, Feb 25, 2017 at 9:50 AM, Leandro Coutinho via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Google recommeds "migrate to safer cryptographic hashes such as SHA-256 and SHA-3"
> > It does not mention RIPEMD-160
> >
> > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1
> >
> >
> > Em 25/02/2017 10:47, "Steve Davis via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> escreveu:
> >
> > > On Feb 24, 2017, at 7:01 PM, Peter Todd <pete at petertodd.org> wrote:
> > >
> > > On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev wrote:
> > >> If the 20 byte SHA1 is now considered insecure (with good reason), what about RIPEMD-160 which is the foundation of Bitcoin addresses?
> > >
> > > SHA1 is insecure because the SHA1 algorithm is insecure, not because 160bits isn't enough.
> > >
> > > AFAIK there aren't any known weaknesses in RIPEMD160,
> >
> > …so far. I wonder how long that vacation will last?
> >
> > > but it also hasn't been
> > > as closely studied as more common hash algorithms.
> >
> > ...but we can be sure that it will be, since the dollar value held in existing utxos continues to increase...
> >
> > > That said, Bitcoin uses
> > > RIPEMD160(SHA256(msg)), which may make creating collisions harder if an attack
> > > is found than if it used RIPEMD160 alone.
> >
> > Does that offer any greater protection? That’s not so clear to me as the outputs (at least for p2pkh) only verify the public key against the final 20 byte hash. Specifically, in the first (notional) case the challenge would be to find a private key that has a public key that hashes to the final hash. In the second (realistic) case, you merely need to add the sha256 hash into the problem, which doesn’t seem to me to increase the difficulty by any significant amount?
> >
> >
> > /s
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:50:35 CEST

- reply

📅 Original date posted:2016-05-11
📝 Original message:On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev wrote:
> On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > There is no way to tell from a block if it was mined with AsicBoost or
> > not. So you don’t know what percentage of the hashrate uses AsicBoost at
> > any point in time. How can you risk forking that percentage out? Note that
> > this would be a GUARANTEED chain fork. Meaning that after you change the
> > block mining algorithm some percentage of hardware will no longer be able
> > to produce valid blocks. That hardware cannot “switch over” to the majority
> > chain even if it wanted to. Hence you are guaranteed to have two
> > co-existing bitcoin blockchains afterwards.
> >
> > Again: this is unlike the hypothetical persistence of two chains after a
> > hardfork that is only contentious but doesn’t change the mining algorithm,
> > the kind of hardfork you are proposing would guarantee the persistence of
> > two chains.
> >
>
> Assuming AsicBoost miners are in the minority, their chain will constantly
> get overtaken. So it will not be one endless hard fork as you claim, but
> rather AsicBoost blocks will continue to be ignored (orphaned) until they
> stop making them.
At least until a difficulty adjustment on the AsicBoost chain takes
place. From that point on, both chains, the AsicBoost one and the
forked one will grow approximately at the same speed.
All the best
Henning
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:49:37 CEST

- reply

📅 Original date posted:2016-03-04
📝 Original message:Hi,
> However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is more akin to an implementation detail, as I
> consider the large-step reward reduction to be.
I do not think that a line can be drawn here. As far as I understood,
you think that the coin limit is a meaningful underlying principle
which should not be touched, whereas the halving of mining rewards is
an implementation detail. The two are very closely tied together and
changes to both of them would result in a hardfork, if I am not
mistaken.
Regarding the effects of the mining reward halving, there is a nice
paper from courtois:
http://arxiv.org/abs/1405.0534
All the best
Henning
On Thu, Mar 03, 2016 at 10:27:35AM -0800, Corey Haddad via bitcoin-dev wrote:
> Since the root cause of what you are trying to address is the reward
> having, I'd suggest considering an adjustment to the having schedule.
> Instead of their being a large supply shock every four years, perhaps the
> reward could drop every 52,500 blocks (yearly), or even at each difficulty
> adjustment, in such a way that the inflation curve is smoothed out. The
> exponential decay rate would be preserved, so overall economic philosophy
> would be preserved.
>
> I'm guessing hesitance to this approach would lie in a reluctance to tinker
> with Bitcoin's 'economic contract', and slippery slope concerns about might
> be the next change (21M?). However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is more akin to an implementation detail, as I
> consider the large-step reward reduction to be.
>
> I'm not too worried about the impact of the having as is, but adjusting the
> economic parameter would be a safer and simpler way to address the concerns
> than to tinker with the difficulty targeting mechanism, which is at the
> heart of Bitcoin's security
>
> On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > We are coming up on the subsidy halving this July, and there have been some
> > concerns raised that a non-trivial number of miners could potentially drop
> > off
> > the network. This would result in a significantly longer block interval,
> > which
> > also means a higher per-block transaction volume, which could cause the
> > block
> > size limit to legitimately be hit much sooner than expected. Furthermore,
> > due
> > to difficulty adjustment being measured exclusively in blocks, the time
> > until
> > it adjusts to compensate would be prolonged.
> >
> > For example, if 50% of miners dropped off the network, blocks would be
> > every
> > 20 minutes on average and contain double the transactions they presently
> > do.
> > Even double would be approximately 850-900k, which potentially bumps up
> > against the hard limit when empty blocks are taken into consideration. This
> > situation would continue for a full month if no changes are made. If more
> > miners drop off the network, most of this becomes linearly worse, but due
> > to
> > hitting the block size limit, the backlog would grow indefinitely until the
> > adjustment occurs.
> >
> > To alleviate this risk, it seems reasonable to propose a hardfork to the
> > difficulty adjustment algorithm so it can adapt quicker to such a
> > significant
> > drop in mining rate. BtcDrak tells me he has well-tested code for this in
> > his
> > altcoin, which has seen some roller-coaster hashrates, so it may even be
> > possible to have such a proposal ready in time to be deployed alongside
> > SegWit
> > to take effect in time for the upcoming subsidy halving. If this slips, I
> > think it may be reasonable to push for at least code-readiness before July,
> > and possibly roll it into any other hardfork proposed before or around that
> > time.
> >
> > I am unaware of any reason this would be controversial, so if anyone has a
> > problem with such a change, please speak up sooner rather than later. Other
> > ideas or concerns are of course welcome as well.
> >
> > Thanks,
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp