> 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 n
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 th
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 p
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 gre
+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 t
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 aspects
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 less
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 signe
> 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 inst
> 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 facto
input amounts (minus any fees he wants to
> contribute). However the only strict requirement is that the receiver
> must never add or remove inputs, and must not ever decrease any
> output amount.
>
> "must never add or remove inputs" - did you mean "must never remove
>
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 /
fa
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 more
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 tr
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 pr
lear that senders can't blindly sign a transaction
without verifying it. The most important thing 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,
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
real
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 overwh
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.
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 thin
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 some
> 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 u
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@lists.linuxfou
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.
P.S.
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 don't think I had a
> sol
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 mined in the near future. If we want to pay
> 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 approac
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 cl
28 matches
Mail list logo