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-14 Thread Erik Aronesty via bitcoin-dev
, where the threshold is built in to the system. Maybe there's another mechanism in there that I'm not aware of - because it's just too simple to mention? - Erik On Thu, Sep 13, 2018 at 2:46 PM Andrew Poelstra wrote: > On Tue, Sep 11, 2018 at 01:37:59PM -0400, Erik Aronesty via bitcoin-

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

Re: [bitcoin-dev] Multiparty signatures

2018-07-08 Thread Erik Aronesty via bitcoin-dev
org> wrote: > Hi Erik, > > On Sun, 2018-07-08 at 10:19 -0400, Erik Aronesty via bitcoin-dev wrote: > > Consider changing the "e" term in the schnorr algorithm to hash of > > message (elligator style) to the power of r, rather than using > > concatenation. > &

[bitcoin-dev] Multiparty signatures

2018-07-08 Thread Erik Aronesty via bitcoin-dev
To save space, start with the wiki terminology on schnorr sigs. Consider changing the "e" term in the schnorr algorithm to hash of message (elligator style) to the power of r, rather than using concatenation. I don't think this changes the security. An attacker would need to know k to either

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal

2018-01-22 Thread Erik Aronesty via bitcoin-dev
Without enforcement liquidity will diverge. On Mon, Jan 22, 2018 at 1:46 PM, Chaofan Li via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi ZmnSCPxj > > I dont think they need to be ENFORCED to be worth the same. > If the two chains’ algorithms are the same , except some

Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks

2017-12-07 Thread Erik Aronesty via bitcoin-dev
You can feel free to write this version and try to get miners to use it. That's the nice thing about Bitcoin. On Thu, Dec 7, 2017 at 3:49 PM, Damian Williamson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning ZmnSCPxj, > > > Actually, there is no incentive to cheat

[bitcoin-dev] BIP103 to 30MB

2017-08-30 Thread Erik Aronesty via bitcoin-dev
If you use this formula, with a decaying percentage, it takes about 100 years to get to 30MB, but never goes past that. Since it never passes 32, we don't have to worry about going past that ever... unless another hard fork is done. A schedule like this could allow block size to scale with tech

Re: [bitcoin-dev] UTXO growth scaling solution proposal

2017-08-22 Thread Erik Aronesty via bitcoin-dev
t once >>> every 10 years or so, which you should be able to do if you have your >>> private keys (you should!). You say it may be something to consider when >>> computer breakthroughs makes old outputs vulnerable, but I say it's not >>> "if" but "wh

Re: [bitcoin-dev] UTXO growth scaling solution proposal

2017-08-22 Thread Erik Aronesty via bitcoin-dev
I agree, it is only a good idea in the event of a quantum computing threat to the security of Bitcoin. On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This seems to be drifting off into alt-coin discussion. The idea that we > can

Re: [bitcoin-dev] UTXO growth scaling solution proposal

2017-08-21 Thread Erik Aronesty via bitcoin-dev
1. If it only affects "old dust" UTXO's where the # of coins in the UTXO aren't sufficient to pay some lower quantile of transaction fees, then there can be little argument of theft or loss. 2. There's another use-case for demurrage as well. Computation power may grow rapidly if quantum

Re: [bitcoin-dev] Would anyone object to adding a dlopen message hook system?

2017-08-15 Thread Erik Aronesty via bitcoin-dev
The idea is that some peers, when you connect to them will work fine for some time, but you need to find out the rate for services and send a micropayment to maintain the connection. This creates an optional pay layer for high quality services, and also creates DDOS resistance in this fallback

Re: [bitcoin-dev] Would anyone object to adding a dlopen message hook system?

2017-08-14 Thread Erik Aronesty via bitcoin-dev
Actually the more I think about it, the more I realize that all I need is to listen on a new port, and use the RPC api to affect Bitcoin: - ban a peer (# of hours) - unban a peer (# of hours) As long as I have those two functions, I can do everything I need. On Sun, Aug 13, 2017 at 4:56 PM,

[bitcoin-dev] Would anyone object to adding a dlopen message hook system?

2017-08-13 Thread Erik Aronesty via bitcoin-dev
I was thinking about something like this that could add the ability for module extensions in the core client. When messages are received, modules hooks are called with the message data. They can then handle, mark the peer invalid, push a message to the peer or pass through an alternate command.

Re: [bitcoin-dev] A Segwit2x BIP

2017-07-14 Thread Erik Aronesty via bitcoin-dev
While BIP91 is probably not terribly harmful, because the vast majority of nodes and users are prepared for it - the hard fork portion of this BIP is being deployed like an emergency patch or quick bug fix to the system. Please consider updating the BIP to include some justification for the

Re: [bitcoin-dev] A Segwit2x BIP

2017-07-08 Thread Erik Aronesty via bitcoin-dev
- The BIP91 portion of the fork seems OK to me. There are some issues with timing, but since this is for miner coordination of segwit activation, and has little to do with other network users, it could be included as an option. (I'm a fan of adding options;plugins, etc. to Bitcoin... some

Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated

2017-06-27 Thread Erik Aronesty via bitcoin-dev
17 6:16 PM, "Hampus Sjöberg via bitcoin-dev" >>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> >>> >>> > Ironically, it looks like most of the segwit2x signaling miners are >>> >>> > faking it

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-23 Thread Erik Aronesty via bitcoin-dev
> They would certainly not be cheap, because they are relatively more expensive due to the extra depreciation cost. This depends on how long you expect to keep money on a side chain and how many transactions you plan on doing. Inflation is a great way of paying PoS / PoB miners - that cannot

Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated

2017-06-20 Thread Erik Aronesty via bitcoin-dev
or >> BIP148) node, because they wouldn't have the new consensus rule of >> requiring all blocks to signal for segwit. >> I don't believe there would be any long lasting chainsplit though >> (because of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if >> we get unluck

[bitcoin-dev] Miners forced to run non-core code in order to get segwit activated

2017-06-20 Thread Erik Aronesty via bitcoin-dev
Are we going to merge BIP91 or a -BIP148 option to core for inclusion in the next release or so? Because a large percentage of miners are indifferent, right now miners have to choose between BIP148 and Segwit2x if they want to activate Segwit. Should we be forcing miners to choose to run

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-20 Thread Erik Aronesty via bitcoin-dev
- a proof-of-burn sidechain is the ultimate two-way peg. you have to burn bitcoin *or* side-chain tokens to mine the side chain. the size of the burn is the degree of security.i actually wrote code to do randomized blind burns where you have a poisson distribution (non-deterministic

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

2017-06-15 Thread Erik Aronesty via bitcoin-dev
> How does the users show their opinion? They can fork away and leave. But what remains will be united. Are you afraid of the united users or the fork? I had proposed earlier and maintain that "UTXO bits" can be used to allow coordinated user participation activation thresholds akin to other

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

2017-06-07 Thread Erik Aronesty via bitcoin-dev
ty supports orphaning >> non-segwit blocks starting Aug 1, I'll join them." >> >> If the real goal of this BIP is to induce miners to run segwit, then fair >> enough. But passing it off as the safest defense is bad faith. >> >> >> On Wed, Jun 7, 2017

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

2017-06-07 Thread Erik Aronesty via bitcoin-dev
BIP is to induce miners to run segwit, then fair > enough. But passing it off as the safest defense is bad faith. > > > On Wed, Jun 7, 2017 at 10:10 AM, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> This is, by far, the safest way f

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

2017-06-07 Thread Erik Aronesty via bitcoin-dev
This is, by far, the safest way for miners to quickly defend against a chain split, much better than a -bip148 option. This allows miners to defend themselves, with very little risk, since the defense is only activated if the majority of miners do so. I would move for a very rapid deployment.

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

2017-06-02 Thread Erik Aronesty via bitcoin-dev
ou mean activate 2X and then spoonet 18 months later > or do not activate the 2x HF at all? > > > > > > On Fri, Jun 2, 2017 at 4:04 PM, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> From me to you ...this proposal doesn't lock in anyt

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

2017-06-02 Thread Erik Aronesty via bitcoin-dev
>From me to you ...this proposal doesn't lock in anything. We could just merge it with some small pushback - allow segwit to activate in Aug, then "upgrade" the hard fork to be "spoonet in 18 months" instead. On Sat, Apr 1, 2017 at 8:33 AM, Jorge Timón via bitcoin-dev <

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

2017-06-02 Thread Erik Aronesty via bitcoin-dev
>From me to you ...this proposal doesn't lock in anything. We could just merge it with some small pushback - allow segwit to activate in Aug, then "upgrade" the hard fork to be "spoonet in 18 months" instead. On Fri, Mar 31, 2017 at 11:03 PM, Samson Mow via bitcoin-dev <

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-30 Thread Erik Aronesty via bitcoin-dev
- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs BIP91 ... how many are there?: https://xkcd.com/927 - If some miners and exchanges collude to enact a rapid 2MB+Segwit hard fork coin... and calling it "bitcoin" on major exchanges this could swiftly fragment the

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

2017-05-29 Thread Erik Aronesty via bitcoin-dev
I can't think of any resistance to this, but the code, on a tight timeline, isn't going to be easy. Is anyone volunteering for this? On May 29, 2017 6:19 AM, "James Hilliard via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > For the reasons listed >

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-29 Thread Erik Aronesty via bitcoin-dev
Seems to me an obvious use case for drive chains are to have high speed small transactions on a side chain, eventually cleared to the main chain. Not sure why miners would want this to fail any more than any other side chain, like Liquid or lightning. On May 28, 2017 5:23 PM, "Peter Todd via

Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

2017-05-26 Thread Erik Aronesty via bitcoin-dev
Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is something that will simply never happen for basic engineering reasons. Spoonet, an oft-quoted hard fork that actually has some strong support, is a much better candidate for the code base - but not of the supposed supporters

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

2017-05-24 Thread Erik Aronesty via bitcoin-dev
Yes, 75% seems fine - given that there is a already a wide deployment of segwit enforcing nodes This implementation is 100% compatible with a "UASF movement" since, if triggered, it essentially turns all supporting miners into equivalent BIP148 enforcers. This should allay any fears that this

Re: [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold

2017-05-23 Thread Erik Aronesty via bitcoin-dev
Instead of block thresholds, use utxo bits to coordinate size changes (larger and smaller should be allowed). There is no reason for miners to be involved in a decision to change this aspects of the protocol. Plenty of other ways to coordinate. Otherwise someone can make it seem to a miner

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

2017-05-23 Thread Erik Aronesty via bitcoin-dev
Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing. I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM growth, of which bandwidth seems the most constraining. - Erik On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev <

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

2017-05-23 Thread Erik Aronesty via bitcoin-dev
Seems like it would work fine. But why would we expect 80pct to signal for the exact same implementation - when we can't get 40pct. It will be contingent on some HF code that allows him to continue using asicboost, or is too aggressive, or some other unreasonable request. On May 22, 2017

Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

2017-05-19 Thread Erik Aronesty via bitcoin-dev
ASIC boost is definitely a protocol vulnerability. It makes Bitcoin resistant to current and future modifications which are necessary to preserve decentralization. That alone should be enough to prioritize a swift preventative measure. On May 18, 2017 3:29 PM, "Ryan Grant via bitcoin-dev" <

Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges

2017-05-08 Thread Erik Aronesty via bitcoin-dev
- It would be cool if any rate-limiting POW was specified as bytecode ... so nodes can plug in as many "machine-captcha" things as they please, and solvers can choose to solve... or just say "nope too hard". - Alternately, it would be a lot nicer if you just required people to pay a nanobit

Re: [bitcoin-dev] Full node "tip" function

2017-05-05 Thread Erik Aronesty via bitcoin-dev
> > This is actually LN’s killer use case - not buying coffees ;) > Yes, micro-payments for online network services is precisely what LN is best at. Establishing a channel with each peer is too expensive. But using LN to micro-pay for high-quality peer services seems like it would aggregate

Re: [bitcoin-dev] Full node "tip" function

2017-05-04 Thread Erik Aronesty via bitcoin-dev
in protocols such as > BitTorrent there is no such tips in sharing files and the blockchain > distribution is in eccense the same thing. However perhaps I am > underestimating the generosity of node operators but I feel that adding a > cost to the blockchain (assuming that all users

Re: [bitcoin-dev] Full node "tip" function

2017-05-04 Thread Erik Aronesty via bitcoin-dev
onable QOS metrics are stored per peer. On Wed, May 3, 2017 at 5:53 PM, Gregory Maxwell <g...@xiph.org> wrote: > On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > CONS: > > The primary result would be

[bitcoin-dev] Full node "tip" function

2017-05-03 Thread Erik Aronesty via bitcoin-dev
IDEA: - Full nodes advertise a bitcoin address. Users that need to download the block chain from that node can be encouraged to send a tip to the peers that served them (by % served). Recommended tip of 10mbit should be fine. - A full nodes can *require* a tip to download the blockchain. If

Re: [bitcoin-dev] Transaction signalling

2017-05-03 Thread Erik Aronesty via bitcoin-dev
BIP : User activated features (ROUGH OVERVIEW) A proposed change to a usage of the 'OP_RETURN' script opcode in Bitcoin transactions, allowing multiple changes (features) to be deployed in parallel. It relies on interpreting the output field as a bit vector, where each bit can be used to

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-05-03 Thread Erik Aronesty via bitcoin-dev
> But as you've observed, the failure probabilities are rather high, > especially if an active attacker targets nodes carrying less commonly > available blocks. Wouldn't the solution be for nodes to use whatever mechanism an attacker uses to determine less commonly available blocks and choose to

Re: [bitcoin-dev] I do not support the BIP 148 UASF

2017-05-02 Thread Erik Aronesty via bitcoin-dev
If the flag day for a wtxid commitment is timed before the current segwit period end, I suspect segwit would activate within the current period. On Tue, Apr 25, 2017 at 2:46 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tuesday 25 April 2017 6:28:14 PM

Re: [bitcoin-dev] Transaction signalling

2017-04-20 Thread Erik Aronesty via bitcoin-dev
I agree, addresses create vulnerability, an OP_RETURN signal seems the safest way to go for UA signalling. I can model a BIP after BIP9, with some discussion of how to properly collect statistics, and the ability for nodes to activate features based on an "economic majority" defined in this way.

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Erik Aronesty via bitcoin-dev
Try to find 1TB dedicated server hosting ... If you want to set up an ecommerce site somewhere besides your living room, storage costs are still a concern. On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1TB HDD is now available

Re: [bitcoin-dev] I do not support the BIP 148 UASF

2017-04-20 Thread Erik Aronesty via bitcoin-dev
problems in Bitcoin, what can we fix? On Thu, Apr 20, 2017 at 10:23 AM, Alphonse Pace <alp.bitc...@gmail.com> wrote: > A WTXID commitment would (likely) need to be a UASF. > > > On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.li

Re: [bitcoin-dev] I do not support the BIP 148 UASF

2017-04-19 Thread Erik Aronesty via bitcoin-dev
The "UASF movement" seems a bit premature to me - I doubt UASF will be necessary if a WTXID commitment is tried first. I think that should be first-efforts focus. On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Apr 15,

Re: [bitcoin-dev] Transaction signalling

2017-04-18 Thread Erik Aronesty via bitcoin-dev
gt; etc. In the very least it would be a far better indicator than simply > counting reachable nodes. > > On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > If users added a signal to OP_RETURN, might it be possible to

[bitcoin-dev] Transaction signalling

2017-04-17 Thread Erik Aronesty via bitcoin-dev
If users added a signal to OP_RETURN, might it be possible to tag all validated input addresses with that signal. Then a node can activate a new feature after the percentage of tagged input addresses reaches a certain level within a certain period of time? This could be used in addition to a

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

2017-04-17 Thread Erik Aronesty via bitcoin-dev
It's too bad we can't make the POW somehow dynamic so that any specialized hardware is impossible, and only GPU / FPGA is possible. Maybe a variant of Keccak where the size of the sponge is increased along with additional zero bits required. Seems like this would either have to resist

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

2017-04-17 Thread Erik Aronesty via bitcoin-dev
On Apr 16, 2017 6:28 PM, <b...@cock.lu> wrote: On 2017-04-16 17:04, Erik Aronesty via bitcoin-dev wrote: > This is a great solution. > > 8 or more secure hashes, each of which can be implemented on GPU/CPU, > but rotate through them - per block round robin. > >

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

2017-04-16 Thread Erik Aronesty via bitcoin-dev
This is a great solution. 8 or more secure hashes, each of which can be implemented on GPU/CPU, but rotate through them - per block round robin. Hardware, infrastructue investment is protected. ASIC is not. Each pow has different tracking metrics and difficulty adjustments. This means the

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-10 Thread Erik Aronesty via bitcoin-dev
2248 <(720)%20515-2248> > g...@cognitive.ch > GPG Key <https://pgp.mit.edu/pks/lookup?op=get=0x0A06E7F9E51DE2D6> > > On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org>, wrote: > > Curious: I'm not sure why a serio

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-09 Thread Erik Aronesty via bitcoin-dev
without it, > multi-megawatt gpu farms have already formed in the areas of the world with > low energy costs. I'd support the goal if I thought it possible, but I > really don't think centralization of mining can be prevented. > > On Apr 9, 2017 1:16 PM, "Erik Aronesty via b

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-09 Thread Erik Aronesty via bitcoin-dev
Curious: I'm not sure why a serious discussion of POW change is not on the table as a part of a longer-term roadmap. Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of the proven, np-complete graph-theoretic or polygon manipulation POW would keep Bitcoin in commodity hardware

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

2017-04-07 Thread Erik Aronesty via bitcoin-dev
It is *not proof of stake.* when: a) burn happens regardless of whether you successfully mine. b) miner cannot know which tx are burns c) the majority of burns cannot be used for mining and are simply lost (poisson discovery distribution) d) burn involves real risk: *every bit as much at stake *

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

2017-04-05 Thread Erik Aronesty via bitcoin-dev
If the primary purpose of pow is to destroy value, then a masked proof of burn to an expanded address that assigns the private key holder the right to mine only in the next Nth block would be sufficient. Expanding the address space so that addresses can only be proven invalid only with the

Re: [bitcoin-dev] Proof-of-Loss

2017-04-05 Thread Erik Aronesty via bitcoin-dev
Is this the same as proof of burn? On Apr 5, 2017 5:28 PM, "Mirelo via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > With the feedback on Proof-of-Loss (always privately to my email), I > realized the article was hard to understand for lacking: > > * A more explicit definition

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

2017-04-05 Thread Erik Aronesty via bitcoin-dev
I personally appreciate the minimal changes, and often encourage development to be done this way - when it needs to be released quickly. But does this need to be released quickly? - maybe the proposal should be renamed segwit 8mb and be discussed solely in terms of block weights. - a high

Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

2017-03-16 Thread Erik Aronesty via bitcoin-dev
Yeah, it does make things harder, and it's easy enough to soft fork to handle arbitrary opt-in protocol improvements, new much larger block sizes, whatever you want. Even OK to migrate to a new system by not allowing old->old or new->old transactions.

[bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

2017-03-15 Thread Erik Aronesty via bitcoin-dev
Some discussion today led me to believe that a post segwit hard fork could include: 1MB old tx non-witness segment XMB new segwit non-witness segment XMB witness segment By partitioning off old transactions, it allows users of older, more expensive validation transactions to continue using them,

Re: [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

2017-03-15 Thread Erik Aronesty via bitcoin-dev
- no quadratic hashing solution - no way to prevent spamming the network to blow up block sizes - no mention of release schedule/consensus levels, etc. should be mentioned - this is similar to other BIP already in place... see BIP107 On Mon, Mar 13, 2017 at 9:08 AM, ashish khandekar via

Re: [bitcoin-dev] High consensus fork system for scaling without limits

2017-03-09 Thread Erik Aronesty via bitcoin-dev
> 1. Allow users to signal readiness by publishing an EB. This EB is an absolute upper bound, and cannot be overridden by miners. Current EB is 1MB, the status-quo. Maybe EB can be configured in a config file, not a UI, since it's an "advanced" feature. > > What does EB stand for? Excessive

[bitcoin-dev] High consensus fork system for scaling without limits

2017-03-08 Thread Erik Aronesty via bitcoin-dev
I woudl like to propose a BIP that works something like this: 1. Allow users to signal readiness by publishing an EB. This EB is an absolute upper bound, and cannot be overridden by miners. Current EB is 1MB, the status-quo. Maybe EB can be configured in a config file, not a UI, since it's an

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

2017-01-06 Thread Erik Aronesty via bitcoin-dev
- N \log_2 \epsilon * 1.44 N = 41000 blocks epsilon = 1/41000 (fp rate) = 904689.8bits ~ 1 MB On Thu, Jul 28, 2016 at 5:07 PM, Leo Wandersleb via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > gmaxwell just made me aware of this mail thread [0]. Some days ago I had >

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

2016-08-12 Thread Erik Aronesty via bitcoin-dev
, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Still not sure how you can take a BIP32 public seed and figure out if an > > address was derived from it though. I mean, wouldn't I have to compute > all > >

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

2016-08-11 Thread Erik Aronesty via bitcoin-dev
11, 2016 at 11:13 AM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Sorr, I thought there was some BIP for a public se

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

2016-08-11 Thread Erik Aronesty via bitcoin-dev
t 7:28 PM, Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > By sending a public seed, there's no way for someone to use the > transmitted > > address and trace the total amount of payments to it. > > Worse. By revealing a public seed,

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

2016-08-10 Thread Erik Aronesty via bitcoin-dev
r the audio would be for watches that can listen but can't >> use a camera (ie: Samsung S2), so sound would be great. >> >> On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> NOTE: &

Re: [bitcoin-dev] BIP clearing house addresses

2016-08-08 Thread Erik Aronesty via bitcoin-dev
I'm not convinced you need to hold people's funds to provide those features. Maybe the millisecond thing. But 99 out of 100 traders would accept a 100 millisecond latency in exchange for 0 counterparty risk. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] BIP clearing house addresses

2016-08-07 Thread Erik Aronesty via bitcoin-dev
I still feel like you're better off getting rid of "hot wallets" and use lightning-esqe networks to route orders. I don't think either speed or flexibility is an issue there. IMO, the point of Bitcoin is to avoid the centralization that seems to be happening on the network now. By making "hot

Re: [bitcoin-dev] BIP clearing house addresses

2016-08-04 Thread Erik Aronesty via bitcoin-dev
https://www.reddit.com/r/Bitcoin/comments/4w016b/use_of_payment_channels_to_mitigate_exchange_risk/ On Thu, Aug 4, 2016 at 12:53 AM, Matthew Roberts via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >This is already possible. Just nLockTime your withdrawls for some future >

Re: [bitcoin-dev] BIP Number Request: Open Asset

2016-08-02 Thread Erik Aronesty via bitcoin-dev
> As said, Open Asset is not a draft proposal and is already used in the wild since 2014. We can't easily modify the protocol by now for improving it. You can, however, provide a new OA2.0 protocol that improves upon these issues, and assure that upgraded wallets maintain support for both

Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin

2016-07-26 Thread Erik Aronesty via bitcoin-dev
- Flags will be mined selfishly, and not published until the advantage gained from withholding is less than the mining reward. This effect may kill the decentralization features, since big miners will be the only ones that can selfish-mine flags. Indeed, collusion would be

Re: [bitcoin-dev] BIP 151

2016-06-30 Thread Erik Aronesty via bitcoin-dev
I agree. Encrypting links in a network without identity doesn't really seem to help enough for the costs to be justified. I would like to see a PGP-like "web of trust" proposal for both the security of the bitcoin network itself /and/ (eventually) of things like transmission of bitcoin

[bitcoin-dev] parallel token idea & question

2016-06-26 Thread Erik Aronesty via bitcoin-dev
token miners who will work to the a new token signal readiness to secure that token by posting a public key to the bitcoin blockchain along with a collateral and possibly a block mined from a side chain, or some other signal proving sufficient participation (allows for non-blockchain tokens).

  1   2   >