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
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. Bu
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
10s of seconds if no further restrictions are placed. It would be trivial to
include a new per input rule that reduces it to ~1s without cutting off any
non-attack script (require sigops per input to be limited to witness/sig size).
secp256k1 is now fast enough that we don’t need a separate sigo
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
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 par
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 t
>
> 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
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.
I am not sure that this discussion is really off topic for this list,
this is a real issue, 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 sec
> 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.
> And I would also extend those concerns
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.
t
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 Argon
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 fit, not empty the whole block and mine
14 matches
Mail list logo
