Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

2018-02-12 Thread Ryan Havar via bitcoin-dev
Thank you very much for writing this up.  It's worth noting that there can be multiple roots for the transactions that are getting replaced. So for rule 3, you probably want a feeRate >= the max "package fee rate" of all replaced roots. I am very happy with this proposal in general, as it's

Re: [bitcoin-dev] Total fees have almost crossed the block reward

2018-02-12 Thread Ryan Havar via bitcoin-dev
> This lead me to ponder whether the intuitive metric of satoshi/byte is, in > fact, game >theory optimal.  Possibly over the short term it is, but over a longer period, >those > wishing to increase the longevity of proof of work in general might wish to > consider > more progressive fee

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

2018-02-12 Thread Ryan Havar via bitcoin-dev
On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev wrote: > I don't actually see where the problem is here. First of all, suppose we have > a > transaction T_a that already pays Alice with a feerate sufficiently high that > we expect it to get

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

2018-02-13 Thread Ryan Havar via bitcoin-dev
On February 13, 2018 1:40 PM, Peter Todd wrote: > Yeah, sorry, I just misread what scenario you guys were talking about. IIRC > the > term "pinned" may have even been invented by myself, as IIRC I noticed the > issue when the RBF patch was being developed years ago. I

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

2018-02-18 Thread Ryan Havar via bitcoin-dev
t validate against pre-segwit rules or are invalid. >Additional rules are applied that further restrict validity, and consider >additional (witness) data in the context of the block. > > e > >>On Feb 18, 2018, at 09:04, Ryan Havar via bitcoin-dev >>bitcoin-dev@l

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

2018-02-18 Thread Ryan Havar via bitcoin-dev
No, you are misunderstanding. The block size limit (1MB) has been replaced in favor of a block weight limit (4M weight). Bytes which must be sent to old clients are weighted at 4 units each which is what allows it to be a soft fork. So as such, there's not two separate limits or anything.

Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale

2018-08-20 Thread Ryan Havar via bitcoin-dev
I think you have correctly identified dealing with small amounts while working in the "bitcoin" denomination as a major pain point, and I will go as far as agreeing that a standard color coding would help people eyeball what 0.11 BTC means if they were used to seeing the same color pallet.

[bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2018-08-30 Thread Ryan Havar via bitcoin-dev
I've just finished writing an implementing of this, and extremely happy with how it turned out. So I'd like to go and try go down the path of more formally describing it and getting some comments and ultimately encourage its wide-spread use. ==Abstract== The way bitcoin transactions are

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2018-09-10 Thread Ryan Havar via bitcoin-dev
g to verify is the output amounts/addresses -- but I will make it more explicit. Thanks once again for your feedback -Ryan ‐‐‐ Original Message ‐‐‐ On Monday, 10 September 2018 05:30, Sjors Provoost wrote: >> Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev >> h

[bitcoin-dev] Creating smaller testnet blocks

2018-07-08 Thread Ryan Havar via bitcoin-dev
More of a shower-thought, but I am currently working on a bitcoin wallet that is designed to handle "free pressure" properly (e.g. CPFP aware, transaction merging, automated progressive fee bumping, etc) and one kind of annoying thing is that there really is no fee market on testnet. I was

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

2018-03-09 Thread Ryan Havar via bitcoin-dev
> Still, re-reading your initital post, I'm convinced that the weakening of the > DoS protections is probably not a huge problem, so maybe lets try this in a > release and see what happens. Awesome! I very much agree. The relaxation of some of these DoS prevention rules I think will really open

Re: [bitcoin-dev] Lookinf for issues to contribute to

2018-03-24 Thread Ryan Havar via bitcoin-dev
Maybe: https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 Just pick something small (even if it's not interesting), struggle with it, struggle with it some more, do a git blame on the parts you need to modify and try contact the person if there's

Re: [bitcoin-dev] Transaction Input/Output Sorting

2018-10-21 Thread Ryan Havar via bitcoin-dev
On Sunday, October 21, 2018 2:54 PM, Pavol Rusnak wrote: > Your solution in the second part of the email does not solve the problem you > indicated in the first part of your email. Sorry, I'm not quite sure what parts you are referring to. I assume you might mean my first paragraph, so I'll

[bitcoin-dev] Transaction Input/Output Sorting

2018-10-21 Thread Ryan Havar via bitcoin-dev
Right now it's just *way* too easy to spot the boundaries between different wallets. There's a lot of things that contribute to that, but the one that concerns me the most is the way wallets sort transaction inputs and outputs. Some wallets and protocols (especially HW wallets) have a strong

Re: [bitcoin-dev] Transaction Input/Output Sorting

2018-10-24 Thread Ryan Havar via bitcoin-dev
Actually, I think it can be calculated a bit smarter using maths (which unfortunately I'm not very good at...). But I assume it's something like: ``` falsePositiveChances := 0.0 foreach( transaction of transactions) { falsePositiveChances += (1 / factorial(transaction.Inputs)) * (1 /

Re: [bitcoin-dev] Transaction Input/Output Sorting

2018-10-24 Thread Ryan Havar via bitcoin-dev
That's pretty easy to quantify. I wrote a quick script to grab the last few blocks, and then shuffle the inputs/outputs before testing if each transaction is bip69 or not. The result was 42% of all transactions would accidentally be bip69 when randomized. So clearly randomization is a lot

Re: [bitcoin-dev] Testnet3 Reest

2018-09-03 Thread Ryan Havar via bitcoin-dev
I think I mentioned it before, but seems semi-relevant to this thread so I'd like to throw my vote behind pretty tiny blocks on testnet (like max 50-100k weight) to try help simulate a fee-market like situation. (Although lately there's been a lot of testnet spam and full blocks, which has

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2019-01-27 Thread Ryan Havar via bitcoin-dev
se any > output amount. > > "must never add or remove inputs" - did you mean "must never remove > inputs"? he surely has to add one! Or, perhaps you mean he must not > alter the list of inputs provided by the sender (in which case it should > be clarified). > >

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2019-01-27 Thread Ryan Havar via bitcoin-dev
> Is there a missing word. "by giving a person.."? Not actually sure what > you're getting at here but I suspect it's again tangential to this BIP > discussion. Correct on both points. I meant to say "giving a (txid:vout:privkey)" to a person as means of payment. > So I think the limiting

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2019-01-27 Thread Ryan Havar via bitcoin-dev
> Why does the template transaction need to be signed in step one and passed > back and forth so many times? What is wrong with: It isn't passed "back and forth so many times". It works exactly as you proposed, with the only difference is in "Step 1" the sender uses a *signed* transaction

Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction

2019-03-21 Thread Ryan Havar via bitcoin-dev
I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well. There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2019-01-30 Thread Ryan Havar via bitcoin-dev
On Tuesday, January 29, 2019 6:06 PM, James MacWhyte wrote: > I'm not convinced this is a valid concern, at least not valid enough to add > extra complications to the process. Signing a transaction is something a wallet needs to be able to do anyway AND at the final-step. And actually a

[bitcoin-dev] Card Shuffle To Bitcoin Seed

2019-02-03 Thread Ryan Havar via bitcoin-dev
More of a shower-thought than a BIP, but it's something I've long wish (hardware) wallets supported: --- Abstract: Bitcoin Wallets generally ask us to trust their seed generation is both correct and honest. Especially for hardware and air gapped wallets, this is both a big ask and more or