Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

e is less than > or equal to the current time. Does that sound right? > > Braun > > > On Sun, Jun 21, 2015 at 10:45 AM, s7r <mailto:s...@sky-ip.org>> wrote: > > Hi > > I don't think that a transaction with nLockTime>0 will be accept

Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

Hi I don't think that a transaction with nLockTime>0 will be accepted by nodes / relayed in the Bitcoin network, until its time expires (e.g. nLockTime==now). This means it obviously cannot be stored in a block, before its locktime expires. nLockTime is designed in a way that you, need to keep it

Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?

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? Thi

Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core

Hi, For the less crypto engineering experts but highly interested in Bitcoin and working with Bitcoin on daily basis reading the list, what would be an easy to understand explanation about how does this solution represent a good fix? So, we have a hard cap of 1 MB block currently. This is not eno

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On 5/28/2015 4:35 PM, Tier Nolan wrote: > On Thu, May 28, 2015 at 1:04 PM, Peter Todd > wrote: > > For that matter, we probably don't want to treat this as a *version* > change, but rather a *feature* flag. > > > I think it is still a version change. At th

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

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 h

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

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

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

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 pare

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

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

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

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 doe

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

power and/or access 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" mailto:s...@sky-ip.org>> > wrote: > > Hi Pieter, > > Thanks for your

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

ny_ future 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&qu

[Bitcoin-development] 75%/95% threshold for transaction versions

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 s

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

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 whic

Re: [Bitcoin-development] SPV clients and relaying double spends

iant Status with Out-of-the-box PCI DSS > Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download > White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with > EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

tions to the network but this will have no effect on me, e.g. can't steal coins or send them on my behalf or intercept my payments, right? It's not clear for me what data would such a node see? Why would you spend money to setup a spy node for this what relevant data can it give

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

is custom Tor node for themselves only, for plausible den. A pool could be the cause as it was earlier discussed here... The thing is I cannot find this node on atlas, globe or blutmagie can you please provide fingerprint and IP address again? So I may ignore it on my relays and talk to s