On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach
andr...@schildbach.de wrote:
On 02/18/2014 08:14 PM, Ryan X. Charles wrote:
BitPay is working on a new standard
based on bitcoin-like addresses for authentication. It would be great if
we could work with the community to establish a complete,
Why introduce a new transaction version for this purpose ? Wouldn't it be more
elegant to simply let:
1. the next bitcoin version prettify all relayed transactions as
deterministic transactions fulfilling the scheme 1-6 effectively blocking any
malleability attack? If miners would upgrade then
On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager grona...@mac.com wrote:
Why introduce a new transaction version for this purpose ? Wouldn't it be
more elegant to simply let:
1. the next bitcoin version prettify all relayed transactions as
deterministic transactions fulfilling the scheme
Thanks for the feedback guys!
I would also like to understand the problems you've been having with
certificates in node.js. FYI the CA cert is *not* supposed to be included,
this matches what the code in Bitcoin Core and bitcoinj expects. It may be
that Bitcoin Core accepts a redundant CA cert
Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions.
-Allen
One possible work-around to get back trusted transaction chaining
Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the fly, but
you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to support it.
Rational use cases of #3 will be pretty hard to find given the
On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager grona...@mac.com wrote:
Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the fly,
but you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
While we might be able to get away with a retroactive change in meaning right
now in the future that won't be so easy. There are lots if proposed
applications for nLockTime-using protocols that depend on transactions (or
parts of transactions)
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd p...@petertodd.org wrote:
While we might be able to get away with a retroactive change in meaning right
now in the future that won't be so easy. There are lots if proposed
applications for nLockTime-using protocols that depend on transactions (or
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com wrote:
I think that we could guarantee fewer incidents by making version 1
transactions unmalleable and then optionally introduce a version 3 that
supported the malleability feature. That way most existing problematic
Regarding chains of transactions intended to be published at once together,
wouldn't it be easier to add a only-mine-with-child flag?
That way the parent transactions aren't actually valid unless spent
together with the transaction that depends on it, and only the original
will have a child
This is somewhat problematic in my use case since some parts need to be in
the chain earlier than others and have the same ID as expected.
https://bitcointalk.org/index.php?topic=260898.10
I haven't gone back to see if there are any ways around it, but the main
problem here is I need the
You could pregenerate entire trees of alternative outcomes where you pick
one branch / chain to broadcast based on the real world events as they
happen.
But I see another problem regarding use of oracles, if you have a P2SH
address with 2-of-3 signatures or similar in the chain, amd some
13 matches
Mail list logo
