On Fri, Mar 16, 2018 at 1:59 AM, Greg Sanders wrote:
> Sorry if I missed the rationale earlier, but why not just do a transaction,
> with a FORKID specifically for this? Then a node can have a mempool
> acceptance test that returns true even if the signature is not valid as per
> Bitcoin consensus
Sorry if I missed the rationale earlier, but why not just do a transaction,
with a FORKID specifically for this? Then a node can have a mempool
acceptance test that returns true even if the signature is not valid as per
Bitcoin consensus, but only due to the FORKID?
This way basically any wallet c
On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr wrote:
> Not necessarily specific UTXOs (that would contradict fungibility, as well as
> be impossible for hot/cold wallet separation), but just to prove funds are
> available. The current sign message cannot be used to prove present possession
> of fun
>
> Good question.. Since you don't really have the input(s), I think it's
> fine to always assume sufficient time/height on CLTV/CSV checks.
>
In this general signing-a-script context, I think a verifier might want to
see the time conditions under which it may be spent. The proof container
could
I don't think the nodes that you are connecting to that have this
behavior are actually forked from Bitcoin Core. It seems more like fake
nodes - nodes that don't actually do any verification or follow the
protocol. Such fake nodes can set whatever user agent they want, common
ones being Bitcoin Co
On Thursday 15 March 2018 7:36:48 AM Karl Johan Alm wrote:
> On Wed, Mar 14, 2018 at 12:36 PM, Luke Dashjr wrote:
> > Ideally, it should support not only just "proof I receive at this
> > address", but also "proof of funds" (as a separate feature) since this
> > is a popular misuse of the current
That is very helpful Luke. I would not have been concerned if it was necessary
to sign multiple times for multiple utxo's on different addresses but, since it
is a feature it may as well be best usable. Signing for multiple inputs
verifying that you have the priv key for each in your wallet is c
Thanks for the reply Andrew. I’ve reviewed the relevant Core sources and I do
not see any problem. We have also synced against a Core node locally and not
seen the problem.
The reason I suspected it was Core is that it is very common and all of the
User Agents are consistent (with an occasional
I like this proposal, it seems sufficiently general.
How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they
always succeed? Or should an nLockTime and nSequence also be included in
the proof in a way that can be parsed out and displayed to verifiers?
I assume any signatures in the
On Wed, Mar 14, 2018 at 12:36 PM, Luke Dashjr wrote:
> Ideally, it should support not only just "proof I receive at this address",
> but also "proof of funds" (as a separate feature) since this is a popular
> misuse of the current message signing (which doesn't actually prove funds at
> all). To d
On Thu, Mar 15, 2018 at 6:43 AM, Jim Posen wrote:
> How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they always
> succeed? Or should an nLockTime and nSequence also be included in the proof
> in a way that can be parsed out and displayed to verifiers?
Good question.. Since you do
11 matches
Mail list logo
