The mail list is public, so it's not like the data on it is somehow
sensitive. Sourcefoge is fine, it has a nice web UI where you can browse
the message and sort/order them as you want, etc.
Why would you want to move to a paid solution? And why would you want
users to have to pay per message?
with tx2
(to know tx2 has a higher fee and needs to substitute tx1) if quite a
lot of params from the transaction structure can change?
Thanks!
On 5/27/2015 4:25 AM, Peter Todd wrote:
On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote:
What is wrong with the man testing some ideas on his custom
What is wrong with the man testing some ideas on his custom branch? This
is how improvements come to life. I saw in the BIPs some really
interesting ideas and nice brainstorming which came from Peter Todd.
Now, my question, if replace by fee doesn't allow me to change the
inputs or the outputs, I
Hello,
How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
b) replays
If you strip just the scriptSig of the input(s), the txid(s) can still
be mutated (with higher probability before it gets confirmed).
If you strip both the scriptSig of the
Thank you all for your comments. The youtube video was indeed very
educative and nice to watch.
It's true that malleability is not the end of the world, but it is
annoying for contracts and micropayment channels, especially refunds
spending the fund tx before it is even in the blockchain, relying
Understood. That is unfortunate, but not the end of the world. If you
could please give feedback also to these last comments / questions:
How far are we at this moment from BIP62? Can an user send a
non-malleable tx now, if enforces some additional rules?
As for the security of the system, it
transaction
version or block version, regardless what changes are made or features
added to bitcoin core? The contract needs to be built and left unchanged
for a very very long period of time...
On 4/16/2015 8:22 AM, Pieter Wuille wrote:
On Apr 16, 2015 1:46 AM, s7r s...@sky-ip.org mailto:s
to my private keys so I would end up not
recognizing my own transaction and probably my change too (if my systems
rely hardly on txid)?
On Apr 16, 2015 9:13 AM, s7r s...@sky-ip.org mailto:s...@sky-ip.org
wrote:
Hi Pieter,
Thanks for your reply. I agree. Allen has a good point
Hi,
Would it be wise to add a consensus rule like the one we have for blocks,
(if 75% from last 1000 blocks are version 'n' mark version 'n' as
standard for blocks and if 95% from the last 1000 blocks are version
'n' mark previous block versions as invalid)
but for transaction versions? In
This should not be enforced by default. There are some use cases where
address re-use is justified (a donation address spread on multiple
static pages or even printed on papers/books?). For example, I offer
some services on the internet for free, and I only have a bitcoin
address for donations
it?
- --
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJT1jXjAAoJEIN/pSyBJlsRjqgIAIFxHcypU6KUaNdSvESADilM
kFiitf00f4Uy9tBwSLVPQw+I2L1EmMiCNvqG4RRjV2+/PS696HCz0Jt0gVaGlMPl
? Why would you spend money to
setup a spy node for this what relevant data can it give you?
- --
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJT1nafAAoJEIN/pSyBJlsR8GYIAL9LkZvPbKjJ6cUxlC4yRKay
12 matches
Mail list logo
