Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

> Not only is JSON limited to editing only through specific software or text > editors, but (in the latter case) it is fragile enough that a single missing > character can cause an entire file to fail parsing. CSV is more forgiving in > this regard. I think quite simply: A forgiving format is

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

I'd strongly suggest not using CSV. Especially for a standard. I've worked with it as an interchange format many a times, and it's always been a clusterfuck. Right off the bat, you have stuff like "The fields may be quoted, but this is unnecessary as the first comma in the line will always be

Re: [bitcoin-dev] Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt)

Of all wallets I've tried, by a huge margin, bitcoin core performs the best with large wallets. I know several massive casinos like bustabit (which has a lot more transactions than your wallet) have been using bitcoin core for large wallets, so it can work. The reason I don't recommend normal

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

What about this? We store a RBU ("relay bandwidth used") with each transaction in the mempool. Where RBU is defined as the size of the transaction + RBU of all transactions it has evicted. For a replacement to be valid: The feerate must be higher than what it's evicting, and the fee must be

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

+1 From an incentive-compatible point of view, miners should be accepting transactions that increase the amount of fees that can achieved with 4M weight of transactions, so it seems like a pretty sane plan. One common problem I've run into with RBF is since you're using RBF you probably want

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

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

[bitcoin-dev] Card Shuffle To Bitcoin Seed

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

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

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

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

> 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] bustapay BIP :: a practical sender/receiver coinjoin protocol

> 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

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] Transaction Input/Output Sorting

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

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] Transaction Input/Output Sorting

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

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

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

Re: [bitcoin-dev] Testnet3 Reest

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

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

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] Suggestion for a universal bitcoin value scale

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] Creating smaller testnet blocks

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] Lookinf for issues to contribute to

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] Revisiting BIP 125 RBF policy.

> 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] Increased blockspace enabled by SegWit limited to just witness data?

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?

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] Revisiting BIP 125 RBF policy.

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] Revisiting BIP 125 RBF policy.

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] Total fees have almost crossed the block reward

> 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.

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