Jim Posen,
A few years ago you mentioned roastbeef’s proposal of a P2P message to
retrieve all prev-outputs for a given block:
1) Introduce a new P2P message to retrieve all prev-outputs for a given
> block (essentially the undo data in Core), and verify the scripts against
> the block by executi
Hi Tim,
Hm, so what vectors is this supposed to mitigate? Leaking through the
> generated public keys? Anything else?
The main thing it’s protecting against is the stealing of your funds by
malicious hardware & software. There are some side benefits as well though.
- What are you trying to ach
Excellent write up, thanks for putting it together.
On Tue, Mar 3, 2020 at 1:47 PM Pieter Wuille wrote:
> When both the HW and the SW are compromised, clearly no security is
> possible,
> as all entities are controlled by the same party in that case.
>
While all SW being compromised can’t be stop
Stepan have you spent any time considering a scheme that could involve HD
keys, preregistering n (ie. 1000) preimages, or something similar to reduce
the number of rounds at time of signing?
Would a zero knowledge solution allow for a reduction in rounds?
On Wed, Feb 26, 2020 at 7:13 PM Stepan Sn
+1 love that progress is being made on this. Excited to implement it once
it’s ready.
Would love if things like the incrementing number were included in the
standard as well.
Cheers! 🍻
On Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Thanks
Does revaulting vault up with the same keys, or new ones?
Are they new derivation paths on the same key?
Would love some expanded explanation on how you’re proposing this would
work.
Thanks,
Dustin
On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.o
Has someone built an analysis of how much extra bandwidth CFB uses over
bloom filters?
Obviously an active merchant in an impoverished country paying data rates
per MB will never be able to afford CFB — so those people are being cut out
of Bitcoin entirely. I suppose the plan is they will rely on
I’ve solved the same problem in a different way.
1) Submit a transaction
2) Collect all reject messages (that have matching txid in the reject data)
3) Wait 16 seconds after first error message received (chosen semirandomly
from trial and error) before processing errors
4) Wait for our txid to be
What about putting it in a deprecated state for some time. Adjust the
transaction weight so using the op code is more expensive (10x, 20x?) and
get the word out that it will be removed in the future.
You could even have nodes send a reject code with the message
“OP_CODESEPARATOR is depcrecated.”
The reject message is helpful for figuring out why a tx was rejected.
It’s not useful for determining success, yes. Particularly when doing
segwit / newer types of tx’s as there’s always one or more pesky nodes who
still don’t support it and send a reject message for perfectly good tx’s.
But afte
How could you prove the private key is in the burning transaction?
On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This could could be a viable option. I think this is the right approach.
>
> Any downside to this and how much does this a
Wouldn’t a revealed private key for time locked funds create a race to
spend? I imagine miners who are paying attention would have the advantage
but it would still just be a race.
Would be nice to have the funds destroyed or sent somewhere specific. Like
if somehow the revealed key was actually it
12 matches
Mail list logo
