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
transac
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 Contract
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 refe
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager 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
> implementations wou
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd 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
> parts of tran
-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) bei
On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager 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 support it.
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 fact
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
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 bei
On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager 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 1-6 effecti
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 the
On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach
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, decentralized
13 matches
Mail list logo
