On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd wrote:
> Speaking of, can anyone think of an example of a complex transaction
> use-case that is affected by malleability which can't be fixed by
> CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
> trying to think of a good example.
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote:
> On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote:
> > I think you can do everything with the existing script level nlocktime
> > in some kind of turing completeness sense (maybe); but there is a
> > complexity cost that often you ha
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote:
> I think you can do everything with the existing script level nlocktime
> in some kind of turing completeness sense (maybe); but there is a
> complexity cost that often you have to resort to extra dependent
> transaction(s) (and work-around malleab
I think you can do everything with the existing script level nlocktime
in some kind of turing completeness sense (maybe); but there is a
complexity cost that often you have to resort to extra dependent
transaction(s) (and work-around malleability until that is fully
fixed) just to get the effect.
By the way, I really like this proposal. I haven't spent much time
thinking about the deeper subtleties and risks associated with it, but I
see a lot of opportunities. One just came to mind that I didn't see
mentioned in his original proposal:
_Non-Interactive Recurring payments__with ID-associa
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn wrote:
>> That is easy to change; I'll submit a pull request.
>
>
> That's certainly a useful improvement. It won't help the existing userbase
> though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.
The next minor release (0.9.4) c
>
> Yes, you're right. I didn't consider that case. But the problem is that
> this is not automatic. Currently there is a clear division between
> miners how will not take the kickback (irrrational) and miners who will
> (rational).
This seems to come up a lot. Your definition of rational is a sh
>
> Opinion: if a soft work works, it should be preferred, if for no other
> reason than once a hard-fork is planned, the discussion begins about
> what else to throw in. To minimize the frequency of hard-forks, the
> time for that is when the change being considered actually requires one.
I'm n
Here is a business idea:
customers send you a bitcoin transaction printed on paper.
You scan the transaction and broadcast it to the network.
Your fee could be the greater of some minimum or like 0.01% of the
transaction value.
The fee could be sent as just another paper transaction, it could even
9 matches
Mail list logo
