Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

2022-07-27 Thread Erik Aronesty via bitcoin-dev
> I'm pretty sure we will have a textbook case of Prisoner's Dilemma here. no, there is no large payoff for betrayal ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

2022-07-26 Thread Erik Aronesty via bitcoin-dev
even with zero block reward and minimal fees, large holders who perform zero transactions will still mine in order to preserve the value of the network this is not "mining your own tx", it is unrelated this is "mining at a small loss to preserve your stake" not only don't we need issuance or

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

2022-07-18 Thread Erik Aronesty via bitcoin-dev
> > > subsidy to directly tie miner revenue to the total value of Bitcoin > makes it not exactly how we want to incentivise a service that keeps > > again, this is meaningless. if the fees aren't enough to keep bitcoin secure for large transactions, then large holders are incentivised to mine

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-14 Thread Erik Aronesty via bitcoin-dev
nstead of trying > to preserve it with corruptible practices outside of market dynamics > principles. > > On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Fees and miner rewards are not needed at all for

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-14 Thread Erik Aronesty via bitcoin-dev
Fees and miner rewards are not needed at all for security at all since long term holders can simply invest in mining to secure the value of their stake. Isn't it enough that the protocol has a mechanism to secure value? Sure fees *might* be enough. But in the event that they are not, large

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread Erik Aronesty via bitcoin-dev
Bitcoin doesn't rely on fees. It relys on users protecting the network out of self interest - running nodes now - mining later It has always been incentivised by holders acting out of self interest If large holders allocating a small percentage to mining to protect their interest, that's all

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-12 Thread Erik Aronesty via bitcoin-dev
> > we can expect mining to transition to a public service from the current > for-profit business model > I get it now Game theory would predict all of the major players mining in the future will be large holders If you're holding a hundred Bitcoin you should take one, sell it for mining

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-11 Thread Erik Aronesty via bitcoin-dev
> > Miners will learn to create anyone-can-spend outputs to bribe other miners > to build on their block rather than reorg it. (Due to the coinbase > maturity, this will require some amount of floating capital.) > (reward + avg fee) * 144 * 365 (one year) == approximate investment needed to

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-11 Thread Erik Aronesty via bitcoin-dev
> If in the future Bitcoin is entirely dependent on fees for security (scheduled very strongly) and this pattern keeps up (overwhelmingly likely) then this is going to become a serious problem. We should carefully define "when" this becomes an issue. Suppose the reward is 1.5625 BTC. That's

Re: [bitcoin-dev] No Order Mnemonic

2022-07-11 Thread Erik Aronesty via bitcoin-dev
Sorry, I totally forgot the checksum. You can take my ops-per-second and multiply it by about 16 (because of the 4 check bits), making a delete + two swaps or 4 swaps, etc. still pretty reasonable. On Mon, Jul 11, 2022 at 9:11 AM Erik Aronesty wrote: > 1. You can swap two positions, and then

Re: [bitcoin-dev] No Order Mnemonic

2022-07-11 Thread Erik Aronesty via bitcoin-dev
1. You can swap two positions, and then your recovery algorithm can brute-force the result by trying all 132 possible swaps. 2. You can make a single deletion and only have to brute 2048 3. You can keep doing these, being aware that it becomes geometrically more difficult each time (deletion +

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

2022-07-11 Thread Erik Aronesty via bitcoin-dev
> > > Alternatively, losses could be at a predictable rate that's entirely > different to the one Peter assumes. > No, peter only assumes that there *is* a rate. Regardless of what the rate is, if it is any value for which there exists *any fixed central tendency*, tail emission is *evenually*

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-07-08 Thread Erik Aronesty via bitcoin-dev
On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil wrote: > Value is subjective, though a constraint of 1tx per 10 minutes seems > unlikey to create a fee of 5000x that of 5000tx. This is of course why I > stated my assumption. Yet this simple example should make clear that at > some point a reduction

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-07-07 Thread Erik Aronesty via bitcoin-dev
The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher. **the ones moving more sats will win the top spots and will pay as much as is reasonable** Smaller blocks produce better security for the network both in

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-07-07 Thread Erik Aronesty via bitcoin-dev
> > We should not imbue real technology with magical qualities. > Precisely. It is economic forces (people), not technology, that provide security. Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives. In addition to "utility",

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-07-07 Thread Erik Aronesty via bitcoin-dev
. > > My thoughts on this are that we will need to periodically make some > software change to adjust a *target amount of investment in security*, > because the > I think perhaps you're underestimating the degree to which utility can be added to the main chain to encourage fees. For example,

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-06-30 Thread Erik Aronesty via bitcoin-dev
> > Anyway, demurrage and inflation have identical economic properties. They're >> both a tax on savings. The only difference is the way that tax is >> implemented. > > the fact that a conversation on inflation is continuing without being ignored is probably an indicator that the utility of

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-06-20 Thread Erik Aronesty via bitcoin-dev
On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > if we start seeing issues with block rewards being too low to maintain > acceptable security, we're going to have multiple solutions being > implemented for it, and definitely a hard

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-06-12 Thread Erik Aronesty via bitcoin-dev
Yes Although I'm guessing most would agree that would be worse. I certainly would choose to add fee generating features over inflation Probably most other people would too On Sat, Jun 11, 2022, 11:36 PM Peter Todd wrote: > On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-06-06 Thread Erik Aronesty via bitcoin-dev
Maintaining the security of the protocol is squarely the responsibility of the Bitcoin software and the core developers Continued demand for block space is critical for Bitcoin's security. Therefore it *is* the responsibility of Bitcoin software and core developers to maintain a continued demand

[bitcoin-dev] signature abstraction

2022-06-03 Thread Erik Aronesty via bitcoin-dev
was thinking it might be possible to create a protocol for signatures where some bounded elliptic curve parameters are in the script, allowing the efficient verification of a broad range of elliptic curves schnorr signatures... rather than a fixed curve has anyone proposed this sort of thing

Re: [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead

2022-05-25 Thread Erik Aronesty via bitcoin-dev
i like the 00 || X_spend || X_scan + mandate address reuse prevention. might as well start with something strict easy to loosen it later - if needed - harder to tighten it later because of back-compatibility with addresses in-use On Tue, May 24, 2022 at 11:02 AM alicexbt via bitcoin-dev <

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

2022-05-14 Thread Erik Aronesty via bitcoin-dev
> > > > FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle > messages and pubkey delegation. The ability to covenants would be > secondary and would mostly serve to get us some real user data about what > sort of covenants users find especially valuable. > I don't think this

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

2022-04-27 Thread Erik Aronesty via bitcoin-dev
> > > > Have you taken a look at my proposal > ? > The proposal is, to be clear, *not* "voting" but rather polling that isn't > programmatically connected to activation. The intention is for people > (developers) to

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

2022-04-27 Thread Erik Aronesty via bitcoin-dev
There are many challenges with on-chain voting, here are a few: - We may not want votes on-chain, because it creates miner incentives for contentious BIP's to drive up fees - Miners can block votes from the chain - Cold storage votes are probably the most important for certain proposals (like

Re: [bitcoin-dev] What to expect in the next few weeks

2022-04-26 Thread Erik Aronesty via bitcoin-dev
> > > I would comment on this point, but I'm not sure I'm "technical enough". I > have to admit: I've never played tennis. > You are technicial enough to read the nacks... everyone is: https://github.com/JeremyRubin/utxos.org/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc I can give a summary

Re: [bitcoin-dev] Speedy Trial

2022-04-26 Thread Erik Aronesty via bitcoin-dev
- it occurs to me that the real problem we have isn't whether miners lead or users lead. we know that users lead, we just need miners to be "ready" and have time to upgrade their software - in the case of "evil" forks, i also don't need or want miners to "defend" bitcoin... (if bitcoin is so

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

2022-04-25 Thread Erik Aronesty via bitcoin-dev
> > > useful!), using APO-AS covers it. And it's not a couple dozen more virtual > bytes that are going to matter for > a potential vault user. > makes sense that byte-efficiency would be likely less important to vault users vs lightning noninteractive channel users > > the meantime others will

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

2022-04-23 Thread Erik Aronesty via bitcoin-dev
On Sat, Apr 23, 2022, 5:05 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > @Zac > > More use cases means more blockchain usage which increases the price of > a transaction for *everyone*. > > This is IMO a ridiculous opposition. Anything that increases the

Re: [bitcoin-dev] Simple step one for quantum

2022-04-11 Thread Erik Aronesty via bitcoin-dev
IW, NTRU and NTRU Prime both made it to round 3 > for > the public key encryption/exchange and digital signature categories, but > both of them seem to be mired in some sort of patent controversy atm... > > -- Laolu > > [1]: https://csrc.nist.gov/Projects/post-quantum-cr

[bitcoin-dev] Simple step one for quantum

2022-04-08 Thread Erik Aronesty via bitcoin-dev
First step could be just implementing a similar address type (secp26k1+NTRU) and associated validation as a soft fork https://www.openssh.com/releasenotes.html#9.0 Then people can opt-in to quantum safe addresses Still should work with schnorr and other things It's a lot of work to fold this

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

2022-02-20 Thread Erik Aronesty via bitcoin-dev
> note how ETH has quite high on chain fees for basic transactions, > because there are so many use-cases where the per-tx value can afford much > higher fees. That kind of expansion of use-case also arguably harms Bitcoin as > a whole by providing more fuel for a future contentious blocksize

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread Erik Aronesty via bitcoin-dev
> As I understand your counterproposal, it would require publishing one transaction per evicted participant. if you also pre-sign (N-2, N-3, etc), you can avoid this > In addition, each participant has to store `N!` possible orderings in which participants can be evicted, as you cannot predict

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread Erik Aronesty via bitcoin-dev
hey, i read that whole thing, but i'm confused as to why it's necessary seems like N of N participants can pre-sign an on-chain transfer of funds for each participant to a new address that consists of (N-1) or (N-1) participants, of which each portion of the signature is encrypted for the same

[bitcoin-dev] bip39

2022-01-17 Thread Erik Aronesty via bitcoin-dev
really don't like that art, work, and artwork are 3 different words would be nice to clean up adjacent ambiguity it's not a big deal, but it can lead to confusion when writing things down dup: ('canal', 'arm') ('can', 'alarm') dup: ('canal', 'one') ('can', 'alone') dup: ('canal', 'ready')

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-10-01 Thread Erik Aronesty via bitcoin-dev
mostly thinking out loud suppose there is a "lightweight" node: 1. ignores utxo's below the dust limit 2. doesn't validate dust tx 3. still validates POW, other tx, etc. these nodes could possibly get forked - accepting a series of valid, mined blocks where there is an invalid but ignored dust

Re: [bitcoin-dev] Drivechain: BIP 300 and 301

2021-09-02 Thread Erik Aronesty via bitcoin-dev
drivechain is a cool proposal. i don't think there's a ton of obvious risk to the network itself (not slow, not too much work for nodes, etc), but it seems to encourage "bad behavior", not sure the incentives line up to prevent thefts, and not sure that won't turn around and bite bitcoin's main

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-08-12 Thread Erik Aronesty via bitcoin-dev
Noe: for A. Chow's upgrade to work, there obviously has to be an effort to deliberately-blacklist unupgraded coins, say after 10-20 years of opportunity to upgrade, or something like that, as long as the transition to quantum isn't so fast that there's no way to do this. On Mon, Mar 22, 2021 at

Re: [bitcoin-dev] Proof of reserves - recording

2021-07-06 Thread Erik Aronesty via bitcoin-dev
you should check out some of the earlier work done here: https://github.com/olalonde/proof-of-solvency#assets-proof to be honest, if any exchange supported that proof, it would be more than enough. there's really no way to prevent a smash-and-grab, but this does prevent a slow-leak On Mon,

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

2021-07-03 Thread Erik Aronesty via bitcoin-dev
i may be ignorant here but i have a question: Given that schnorr signatures now allow signers to perform complex arithmetic signing operations out-of-band using their own communications techniques, couldn't you just perform the publishing and accumulation of these signature components without

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-07-01 Thread Erik Aronesty via bitcoin-dev
your protocol should always assume the email system is fully compromised, and only send public information over email: - public keys / addresses are sent - other routing data encrypted with public keys (not sure how data is routed in sabu) your end user should be able to verify public keys /

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-06-24 Thread Erik Aronesty via bitcoin-dev
> PoS is not suitable for use as a consensus system, because it is constitutionally incapable of producing a consensus. true - but only for a system that is starting from nothing. since bitcoin already exists, and we have a consensus, you can use bitcoin's existing consensus to maintain that

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-19 Thread Erik Aronesty via bitcoin-dev
ifferent, conflicting transactions. Nodes will need a way > > to all come to consensus on what the right set of “sent notes” is. > > I think you will end up reinventing a lot of the problems solved by > > bitcoin. > > > > Why did you pick email as the RPC mechan

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-18 Thread Erik Aronesty via bitcoin-dev
It is vulnerable to sybil attacks or where the recipient is a victim of a proxy attack. If the recipient is not connected to a valid Network, then double spends could be allowed. as long as this protocol is intended for use of transactions around a dollar or so I don't see that being a

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-18 Thread Erik Aronesty via bitcoin-dev
for very small transactions, this seems to make a hell of a lot of sense. it's like lightning, but with no limits, no routing protocols... everything is guaranteed by relative fees and the cost-of-theft. pretty cool. On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev wrote: > > Hi, > I have

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-06-01 Thread Erik Aronesty via bitcoin-dev
> the classical debate with PoS supporters - I explain an attack and they > "patch it", creating problem elsewhere i agree. my original post was: "assume that we can accurately mimic the investment in ASIC's and the expenditure of electricity with "burns" of coin representing that

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-28 Thread Erik Aronesty via bitcoin-dev
nsibilities on the holder to > > > > > > > > > > maintain the quality of all the other bars of gold out > > > > > > > > > > there. > > > > > > > > > > Bitcoin feels like this too and in many ways is more i

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-27 Thread Erik Aronesty via bitcoin-dev
> > For Bitcoin to succeed I think we need to keep it that way and >>>> >> >> > Proof-of-Stake makes everything a bit too exciting. >>>> >> >> > >>>> >> >> > I suppose in the end the market will decide what

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-26 Thread Erik Aronesty via bitcoin-dev
and bias against Proof of >>> >> >> >> Stake. Yes there have been lots of shady coins that use insecure >>> >> >> >> PoS mechanisms. Yes there have been massive issues with >>> >> >> >> distribution of PoS coins (of course there have

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-25 Thread Erik Aronesty via bitcoin-dev
act have clear centralization >> >> >> pressure - this is not disputed. Our goal in relation to that is to >> >> >> ensure that the centralization pressure remains insignifiant. Proof of >> >> >> work also clearly has a lot more barriers to entry than

Re: [bitcoin-dev] Reducing block reward via soft fork

2021-05-25 Thread Erik Aronesty via bitcoin-dev
> > I don't think 99% of transactions need that level of security > Well you can't get security for the 1% of transactions that need it without > giving that security to all transactions on the chain. Also, the blockchain > security created by miners isn't really a per transaction thing

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-25 Thread Erik Aronesty via bitcoin-dev
ause as the attacker accumulates hashpower, it >> >> drives honest miners out of the market as the difficulty increases to >> >> beyond what is economically sustainable. Also, its been shown that the >> >> best proof of work can do is require an attacker to obtain 3

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-24 Thread Erik Aronesty via bitcoin-dev
ns of timestamping to regulate >> > overproduction of blocks >> >> Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed to >> double their clock speeds. Both systems rely on an honest majority sticking >> to standard time. >> >&g

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

2021-05-21 Thread Erik Aronesty via bitcoin-dev
anism. > However, how to do this in a soft fork is another story. It sounds like its > doable from other people's comments. > > On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev > wrote: >> >> On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bi

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-21 Thread Erik Aronesty via bitcoin-dev
>>> going on these topics already where they would be relevant. >>> >>> Also, it's important to distinguish between oPoW and these other >>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter >>> the core game theo

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-18 Thread Erik Aronesty via bitcoin-dev
1. i never suggested vdf's to replace pow. 2. my suggestion was specifically *in the context of* a working proof-of-burn protocol - vdfs used only for timing (not block height) - blind-burned coins of a specific age used to replace proof of work - the required "work" per block would simply be a

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-17 Thread Erik Aronesty via bitcoin-dev
Verifiable Delay Functions involve active participation of a single verifier. Without this a VDF decays into a proof-of-work (multiple verifiers === parallelism). The verifier, in this case is "the bitcoin network" taken as a whole. I think it is reasonable to consider that some

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-10 Thread Erik Aronesty via bitcoin-dev
personally, not speaking for anyone else, i think that proof-of-burn has a much higher likelihood of being a) good enough security and b) solving the nothing-at-stake problem the only issue i see with a quality PoB implementation is a robust solution to the block-timing problem.

Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed

2021-05-06 Thread Erik Aronesty via bitcoin-dev
i would stretch the password, with pbkdf2 or argon2 with like 30k rounds or something first, rather than "just hashing it". remember, it's pretty easy to validate these seeds - not like you lock someone out after 9 guesses! On Wed, May 5, 2021 at 3:38 PM Tobias Kaupat via bitcoin-dev wrote: > >

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

2021-04-27 Thread Erik Aronesty via bitcoin-dev
seems like this is solved by a workflow where a maintainer who requests changes clearly tags every entry as "changes needed" or "review requested",, and then the author can resolve/remove the tag after the changes are made. not sure PR's are the right tech here. On Tue, Apr 27, 2021 at 6:28 AM

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

2021-04-16 Thread Erik Aronesty via bitcoin-dev
; Imagine one miner turns on a S9 and then ramps up difficulty for everyone > else. > > On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev > wrote: >> >> Not sure of the best place to workshop ideas, so please take this with >> a grain of salt. &g

[bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

2021-04-16 Thread Erik Aronesty via bitcoin-dev
Not sure of the best place to workshop ideas, so please take this with a grain of salt. Starting with 3 assumptions: - assume that there exists a proof-of-burn that, for Bitcoin's purposes, accurately-enough models the investment in and development of ASICs to maintain miner incentive. - assume

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

2021-04-10 Thread Erik Aronesty via bitcoin-dev
here's what we do for multisig: - each member generates their own public/private key pair first and publishes the pair to all other members - members are then verified using a secondary channel, like a phone call ... where the H128(pubk) is turned into BIP-words for manual/visual verification -

[bitcoin-dev] maximum block height on transaction

2021-04-09 Thread Erik Aronesty via bitcoin-dev
is there any way to specify a maximum block height on a transaction? ie: this tx is only valid if included in a block with a certain height or less i feel like this would be useful ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Announcing a new standard for soft fork activation

2021-04-05 Thread Erik Aronesty via bitcoin-dev
this satire points out the "bikeshedding" problem, or the "law of triviality". a problem is discussed in proportion to the number of people who feel qualified to talk about them. few users are experts at the cryptography, and even fewer are experts at c++, cryptography and possibly game theory

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-03-22 Thread Erik Aronesty via bitcoin-dev
The argument that hashed public addresses provide meaningful quantum resistance is flawed *when considered in the context*.of Bitcoin itself. This article by Andrew Chow is easy to read and makes a strong case against the quantum utility of hashed public keys:

Re: [bitcoin-dev] An alternative to BIP 32?

2021-03-22 Thread Erik Aronesty via bitcoin-dev
alternative > without relying on sha3? That should at the very least eliminate length > extension attacks. > > Best, > Arik > > > On Mar 19, 2021, at 6:32 PM, Erik Aronesty via bitcoin-dev > > wrote: > > > > use sha3-256. sha256 suffers from certain attacks (l

Re: [bitcoin-dev] An alternative to BIP 32?

2021-03-19 Thread Erik Aronesty via bitcoin-dev
use sha3-256. sha256 suffers from certain attacks (length extension, for example) that could make your scheme vulnerable to leaking info, depending on how you concatenate things, etc. better to choose something where padding doesn't matter. On Fri, Mar 19, 2021 at 7:28 PM vjudeu via bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

2021-03-16 Thread Erik Aronesty via bitcoin-dev
Any proposed hard fork will wind up being some sort of Bitcoin sv thing no matter what you propose or no matter how awesome it is they'll be many people in the community who would prefer to continue business as usual. which I'd like to point out seems to be working very, very well. so you should

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

2021-03-12 Thread Erik Aronesty via bitcoin-dev
secp236k1 isn't a hashing algo. your BIP needs about 10 more pages and some degree of technical merit. i suggest you start here: https://en.bitcoin.it/wiki/Proof_of_burn https://bitcointalk.org/index.php?topic=225690.0 proof-of-burn is a nice alternative to proof-of-work. i always suspected

Re: [bitcoin-dev] Taproot NACK

2021-03-04 Thread Erik Aronesty via bitcoin-dev
taproot does not enable anything that cannot already be done today. it only enables larger and more complex scripts to be done more efficiently - using less ledger space. so any objections you can have should be leveled at bitcoin, not at taproot. On Wed, Mar 3, 2021 at 6:39 AM LORD HIS

Re: [bitcoin-dev] MASF=true + LOT=informational

2021-03-04 Thread Erik Aronesty via bitcoin-dev
And of course: 1) MASF=true + LOT=eventually true Using a declining activation threshold over time gives miners control only over the timing of activation, not the eventuality. This is essentially the same as LOT=true, however, it has a greater chance of activation without requiring

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

2021-03-01 Thread Erik Aronesty via bitcoin-dev
This is the declining percentage of signaling activation. It has all the benefits of both. Eventually it becomes a LOT=true, so any argument for LOT=true holds And all of the arguments for LOT=false are satisfied by the cool down period. On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-03-01 Thread Erik Aronesty via bitcoin-dev
> Today users should start cooperating again to continue using the > optimal strategy. the "gradual" method of reducing the % of miners required for lock-in as time goes on seems to encode this optimal strategy. On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev wrote: > > On Tue, Feb

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-21 Thread Erik Aronesty via bitcoin-dev
I think the most important thing is that the configuration setting is advertised if somebody were to query the node for its capabilities. Is this the case? That way the default value isn't really the important thing. There are longstanding and well-known nodes, for example. Community support

Re: [bitcoin-dev] BIP Proposal: Wallet Interface

2020-12-23 Thread Erik Aronesty via bitcoin-dev
Obviously Bitcoin has a wallet api, intermingled with other protocol APIs: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list For security, a standard wallet API should write a token/port to a local file where the user can grab that token and use it (that's basically how the

Re: [bitcoin-dev] hashcash-newhash

2020-05-27 Thread Erik Aronesty via bitcoin-dev
> What you are focusing on is only this: > > * Proof-of-work. Bitcoin's primary value proposition is that it's the most resistant to change: All other coins are these malleable things centrally controlled and easily moved about by politics and nonsense. So discussions of POW changes... open

[bitcoin-dev] Schnorr sigs vs pairing sigs

2020-03-05 Thread Erik Aronesty via bitcoin-dev
Schnorr sigs rely so heavily on the masking provided by a random nonce. There are so many easy ways to introduce bias (hash + modulo, for example). Even 2 bits of bias can result in serious attacks: https://ecc2017.cs.ru.nl/slides/ecc2017-tibouchi.pdf Maybe pairing based sigs - which are

Re: [bitcoin-dev] Composable MuSig

2020-02-24 Thread Erik Aronesty via bitcoin-dev
same message twice, it should help reduce the attack surface. On Mon, Feb 24, 2020 at 6:41 AM Tim Ruffing via bitcoin-dev wrote: > > On Sun, 2020-02-23 at 02:27 -0500, Erik Aronesty via bitcoin-dev wrote: > > > Thus, two-phase MuSig is potentially unsafe. > > > https

Re: [bitcoin-dev] Composable MuSig

2020-02-23 Thread Erik Aronesty via bitcoin-dev
> Thus, two-phase MuSig is potentially unsafe. > https://eprint.iacr.org/2018/417.pdf describes the argument. One solution is to add a signature timeout to the message (say a block height) . A participant refuses to sign if that time is too far in the future, or is at all in the past, or if a

Re: [bitcoin-dev] Transition to post-quantum

2019-10-24 Thread Erik Aronesty via bitcoin-dev
- It would be hard to prove you have access to an x that can produce H(g^x) in a way that doesn't expose g^x and isn't one of those slow, interactive bit-encryption algorithms. - Instead a simple scheme would publish a transaction to the blockchain that lists: - pre-quantum signature -

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-12 Thread Erik Aronesty via bitcoin-dev
> That approach has its uses but I think that in any case where delinearization can be used it's a better option. I agree, communication efficiency is a concern for some applications, and I can think of cases where delinearization is the better option as well. For users that want an "M of N"

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-12 Thread Erik Aronesty via bitcoin-dev
- Musig, by being M of M, is inherently prone to loss. - Having the senders of the G*x pubkey shares sign their messages with the associated private key share should be sufficient to prevent them from using wagner's algorithm to attack the combined key. Likewise, the G*k nonce fragments should

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-12 Thread Erik Aronesty via bitcoin-dev
Greg, I added, stripped out, and added analogous musig delinearization 3 times in response to stuff posted here. I'm adding it back now. Not sure why my head is thick around that issue. The security advantages of a redistributable threshold system are huge. If a system isn't redistributable,

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-12 Thread Erik Aronesty via bitcoin-dev
omeone who has M-1 keys. I haven't tested whether the R,s version is susceptible though. On Thu, Sep 6, 2018 at 9:15 AM Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev > wrote: &g

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-05 Thread Erik Aronesty via bitcoin-dev
Correct, there is an interaction step to deduce G*k, when signing, each participant has to publishes G*ki. I didn't talk about it. That doesn't break it, but you're correct, it's not non-interactive. On Wed, Sep 5, 2018 at 9:06 AM Andrew Poelstra wrote: > On Wed, Sep 05, 2018 at 08:26:14AM

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-05 Thread Erik Aronesty via bitcoin-dev
Why would you call it FUD? All the weird hemming and hawing about it is really strange to me. The more I look into it and speak to professors about i, the more it seems "so trivial nobody really talks about it". 1. Generate an M of N shared public key (done in advance of signing this gets

Re: [bitcoin-dev] Schnorr signatures BIP

2018-08-29 Thread Erik Aronesty via bitcoin-dev
Note: This spec cannot be used directly with a shamir scheme to produce single-round threshold multisigs, because shares of point R would need to be broadcast to share participants in order to produce valid single signatures. (R, s) schemes can still be used "online", if share participants

Re: [bitcoin-dev] Multisignature for bip-schnorr

2018-08-29 Thread Erik Aronesty via bitcoin-dev
It's cool but - there's a lot of online steps. - it's not a threshold system Using a shamir scheme solves this and isn't subject to birthday attacks: https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f On Mon, Aug 13, 2018 at 7:08 AM nakagat via bitcoin-dev <

Re: [bitcoin-dev] Multiparty signatures

2018-07-25 Thread Erik Aronesty via bitcoin-dev
Also we don't need any new opcodes to support this. Done right this could literally go out into clients immediately. On Fri, Jul 20, 2018, 4:18 PM Erik Aronesty wrote: > Sorry there were typos: > > - Using MuSig's solution for the blinding factor (e) > - Using interpolation to enhance MuSig to

Re: [bitcoin-dev] Multiparty signatures

2018-07-22 Thread Erik Aronesty via bitcoin-dev
Sorry there were typos: - Using MuSig's solution for the blinding factor (e) - Using interpolation to enhance MuSig to be M of N instead of M of M References: - MuSig https://blockstream.com/2018/01/23/musig-key-aggregation- schnorr-signatures.html - HomPrf

Re: [bitcoin-dev] Multiparty signatures

2018-07-22 Thread Erik Aronesty via bitcoin-dev
Hi, thanks for all the help. I'm going to summarize again, and see if we've arrived at the correct solution for an M of N "single sig" extension of MuSig, which I think we have. - Using MuSig's solution for the blinding to solve the Wagner attack - Using interpolation to enhance MuSig to be M

Re: [bitcoin-dev] Multiparty signatures

2018-07-22 Thread Erik Aronesty via bitcoin-dev
Getting a nice Shamir m of n multisig with a single signature...and all the same properties otherwise. On Thu, Jul 19, 2018, 9:11 AM Russell O'Connor wrote: > On Thu, Jul 19, 2018 at 8:16 AM, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >

Re: [bitcoin-dev] Multiparty signatures

2018-07-19 Thread Erik Aronesty via bitcoin-dev
ed a public X >> coordinate as well as a secret share. Choosing hash(pub) as X, prevents >> this attack. >> >> >> On Wed, Jul 11, 2018 at 6:35 AM, Adam Back wrote: >> >>> On Wed, Jul 11, 2018, 02:42 Erik Aronesty via bitcoin-dev < >>

Re: [bitcoin-dev] Multiparty signatures

2018-07-19 Thread Erik Aronesty via bitcoin-dev
, you need a public X coordinate as > well as a secret share. Choosing hash(pub) as X, prevents this attack. > > > On Wed, Jul 11, 2018 at 6:35 AM, Adam Back wrote: > >> On Wed, Jul 11, 2018, 02:42 Erik Aronesty via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundati

Re: [bitcoin-dev] Multiparty signatures

2018-07-11 Thread Erik Aronesty via bitcoin-dev
construction, yes... adaptive attacks are possible. But in a shamir secret sharing interpolation, you need a public X coordinate as well as a secret share. Choosing hash(pub) as X, prevents this attack. On Wed, Jul 11, 2018 at 6:35 AM, Adam Back wrote: > On Wed, Jul 11, 2018, 02:42 Erik Aronesty

Re: [bitcoin-dev] Multiparty signatures

2018-07-10 Thread Erik Aronesty via bitcoin-dev
Basically you're just replacing addition with interpolation everywhere in the musig construction. But maybe I just don't understand how Wagner's algorithm is relevant here. On Mon, Jul 9, 2018, 1:59 PM Erik Aronesty wrote: > - Adaptive r choice shouldn't be possible since r is derived from

Re: [bitcoin-dev] Multiparty signatures

2018-07-09 Thread Erik Aronesty via bitcoin-dev
- Adaptive r choice shouldn't be possible since r is derived from the original threshold prf and it's not possible for a party to have any adaptive impact on the value of r - I'm guess I don't see how an attacker can use adaptive key choice in this context either. Any modification of the key

Re: [bitcoin-dev] Multiparty signatures

2018-07-09 Thread Erik Aronesty via bitcoin-dev
Actually, it looks like in order to compute a multiparty signature you will need to broadcast shares of r first, so it's not offline :( It is still seems, to me, to be a simpler mechanism than musig - with security assumptions that match the original Schnorr construction more closely, and should

Re: [bitcoin-dev] Multiparty signatures

2018-07-09 Thread Erik Aronesty via bitcoin-dev
something I've been tinkering with and I can't see an obvious problem. It's basically the same as schnorr, but you use a threshold hash to fix the need to be online. Just seems more useful to me. On Sun, Jul 8, 2018, 10:33 PM Pieter Wuille wrote: > On Sun, Jul 8, 2018, 19:23 Erik Aronesty via bitc

  1   2   >