Re: [bitcoin-dev] Version 1 witness programs (first draft)

Clean stack should be eliminated for other possible future uses, the most obvious of which is recursive tail-call for general computation capability. I’m not arguing for that at this time, just arguing that we shouldn’t prematurely cut off an easy implementation of such should we want to. Clean

Re: [bitcoin-dev] Version 1 witness programs (first draft)

Should it perhaps commit to the length of the serialised witness data instead or additionally? Now that signatures are no longer variable-length, that'd be possible... As far as tail-call needs are concerned, CLEANSTACK wouldn't have been checked until AFTER the tail-call in the first draft.

Re: [bitcoin-dev] Version 1 witness programs (first draft)

The CLEANSTACK rule should be eliminated, and instead the number of items on the stack should be incorporated into the signature hash. That way any script with a CHECKSIG is protected from witness extension malleability, and those rare ones that do not use signature operations can have a “DEPTH

[bitcoin-dev] Version 1 witness programs (first draft)

I've put together a first draft for what I hope to be a good next step for Segwit and Bitcoin scripting: https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki This introduces 5 key changes: 1. Minor versions for witnesses, inside the witness itself. Essentially the witness

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

By "all of this" I meant the other issues that I mentioned too "would everybody even here say that they feel very comfortable with their keys? That if something happen to them there is no pb for the family or trusted parties to retrieve the keys? That this process is secured in case the trusted

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

On Thursday 07 September 2017 12:38:55 AM Mark Friedenbach via bitcoin-dev wrote: > Tail-call execution semantics > BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368 > Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics Just noticed this doesn't count sigops toward

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

> > uhh do you apply this logic to the bitcoin-core wallet itself? > because clearly it generates keys and is intended to be used for signing > in online environments. Lots of real-world use-cases depend on that today. The current Bitcoin Core wallet setup is not as ideal as it could be. An

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

Generally agreed. This is why I nack'ed BIP72 years ago when we discussed about standardization. However, there are many ways to use BIP70 without BIP72. BIP72 is just a kludge to biggy-pack the payment protocol onto BIP21. And also, as you note, BIP72 can be easily fixed using a hash parameter.

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

> Op 30 sep. 2017, om 06:49 heeft Jonas Schnelli via bitcoin-dev > het volgende geschreven: > >> On 09/29/2017 02:03 PM, Luke Dashjr wrote: >> Paper wallets are a safety hazard, insecure, and generally not advisable. >> > > I have to agree with Luke. >

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

On 09/29/2017 09:49 PM, Jonas Schnelli wrote: > AFAIK, client implementations such as your proposal are off-topic for this ML. > Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such > proposals. ok, thanks. I will take the proposal there. > I have to agree with Luke.

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

I'm happy to help with secure paper wallet support. Bitcoin core is already used offline by the Glacier Protocol, though there's no official offline support. I extended the Glacier Protocol with an extra password derivation function. I used Scrypt with 2GB RAM requirement, though maybe using

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

On Sat, Sep 30, 2017 at 3:55 AM, Jorge Timón via bitcoin-dev wrote: > Gmaxwell I think what's new is that in this case, with a single tx you would > take out all txs with fee below 1 btc. With current rules, you would only > remove enoguh txs for that one to