On Wed, May 7, 2014 at 2:07 PM, Wladimir wrote:
> On Wed, May 7, 2014 at 10:25 PM, Mike Hearn wrote:
>> Another is to export stats over regular TCP and make them public so
>> literally anyone can listen to the stats feed for any node.
>
> TOR does this as well: http://torstatus.blutmagie.de/
>
>
I've noticed some folks struggling to attach labels to their yet to be
numbered BIPs.
I'd recommend people call them "draft--" like draft-maxwell-coinburning in the style of pre-WG IETF
drafts.
--
"Accelerate Dev Cycles w
On Mon, May 12, 2014 at 10:01 AM, Matt Whitlock wrote:
> Why is there such a high bar to getting a number assigned to a BIP anyway?
> BIP 1 seems to suggest that getting a BIP number assigned is no big deal, but
> the reality seems to betray that casual notion. Even proposals with hours of
> wo
On Thu, May 15, 2014 at 4:50 AM, Andreas Schildbach
wrote:
> I'm bringing this issue up again. The current Bitcoin DNS seed
> infrastructure is unstable. I assume this is because of we're using a
> custom DNS implementation which is not 100% compatible. There have been
> bugs in the past, like a c
On Sat, May 17, 2014 at 9:07 AM, Chris Pacia wrote:
> I can't really just hand someone the note and walk away
> because they have to scan it to see if it is actually valid.
Not just scan it, but they actually must successfully sweep it—
otherwise they can be trivially double spent. This is especi
On Mon, May 19, 2014 at 8:09 AM, Mike Hearn wrote:
> The first rule of patents is you do not go looking for patents. US law is
> written in a really stupid way, such that if you knowingly infringe, damages
> triple. Because America uses the patent office as a revenue source,
You have received out
On Mon, May 19, 2014 at 1:01 PM, Justus Ranvier wrote:
> YOU can make promises about YOUR future behavior. So can everyone else.
>
> The rest of the community can keep track of which developers will and
> will not make promises about what changes they will and will not
> attempt to implement in Bi
On Wed, May 21, 2014 at 1:30 PM, Mark Friedenbach wrote:
> Honest question: what would signed commits do to help us here anyway?
> What's the problem being solved?
>
> Unfortunately git places signatures in the history itself, so it's not
> like we could use easily use signatures to indicate accep
On Fri, May 23, 2014 at 9:48 AM, Kyle Jerviss wrote:
> Multisig is great for irreversible actions, but pointless most of the
> time, which is why no PGP developer or user ever thought to implement it.
>
> If you lose a key and an attacker signs a bogus email or commit with it,
> we all roll back w
On Fri, May 23, 2014 at 8:57 PM, Ashley Holman wrote:
> Hi,
> On this list there has been some discussion around techniques to speed up
> block propagation, with a particular focus on reducing the extra orphan risk
> carried by larger blocks.
> The current store-and-forward method means that large
On Sat, May 24, 2014 at 5:04 PM, Alan Reiner wrote:
> I think the most important change is modifying the way Bitcoin Core
> prioritizes blocks. Right now it uses the first full block verified.
> Instead, it should consider the first valid header received as highest
> priority, but only mine on it
On Sun, May 25, 2014 at 2:36 AM, Mike Hearn wrote:
> Although this is a somewhat appealing notion, would it really improve
> feature velocity? I don't think the current p2p protocol is holding anything
> back, and having to implement features twice in two protocols would slow
> things down quite a
On Fri, May 30, 2014 at 8:40 AM, Andreas Schildbach
wrote:
> I maybe have made this suggestion in the past, but why don't we teach
> the seeder (or maybe even plain bitcoind) how to write a zone file and
> then use matured DNS servers to serve this zone?
>
> I admit I never ran my own DNS so I'm n
On Mon, Jun 2, 2014 at 12:39 AM, Wladimir wrote:
> If that is done, I'm not sure how much a global setting in the status
> bar would add. It may make it more apparent to the user that multiple
> units can be selected.
If thats done it should be done in a way in which it's impossible that
a stray
On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn wrote:
> Hi Ron,
>
> FYI your mail is being spamfoldered due to Yahoo's DMARC policy and the
> brokenness of the SF.net mailing list software. I would not expect to get
> replies reliably whilst this is the case. I think we should move away from
> SF.net
On Wed, Jun 4, 2014 at 3:20 AM, Mike Hearn wrote:
>> As a matter of procedure we do not use assertions with side effects— the
>> codebase did at one point, but have cleaned them up. In an abundance of
>> caution we also made it refuse to compile without assertions enabled: A
>> decision who's wis
On Fri, Jun 6, 2014 at 1:48 AM, Adam Back wrote:
> Advertising NODE BLOOM as a service sounds good.
>
> But the critique of bloom filters, I am not so sure prefix filters are
> better. Prefix filters offer questionable privacy tradeoffs in my opinion.
> Same problem as with stealth address propos
On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd wrote:
> transactions against. Where they differ is that bloom filters has O(n)
> scaling, where n is the size of a block, and prefix filters have O(log n)
> scaling with slightly(1) higher k. Again, if you *don't* use brute forcing
> in conjunction with
On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd wrote:
> Again, you *don't* have to use brute-force prefix selection. You can
> just as easily give your peer multiple prefixes, each of which
> corresponds at least one address in your wallet with some false positive
> rate. I explained all this in deta
On Mon, Jun 9, 2014 at 11:13 AM, Richard Moore wrote:
> Hey all again,
>
> I am implementing BIP38 wallets right now, and had another idea I would like
> to put out there for discussion.
>
> Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was
> wondering if it would make sense t
On Tue, Jun 17, 2014 at 2:14 PM, Odinn Cyberguerrilla
wrote:
> Hoping that this is the right place for this, I am asking a question as to
> what happens with what is in the CoinJoin bounty fund address at:
The correct place for more information is the Bitcointalk forum thread
where it was announc
On Fri, Jul 4, 2014 at 3:27 AM, Andy Parkins wrote:
> Hello,
>
> I had a thought after reading Mike Hearn's blog about it being impossible to
> have an ASIC-proof proof of work algorithm.
>
> Perhaps I'm being dim, but I thought I'd mention my thought anyway.
Thanks for sharing. Ideas similar to
On Wed, Jul 16, 2014 at 7:25 AM, Jeff Garzik wrote:
> On the specific issue I raised, the BIP only says "Querying multiple
> nodes and combining their answers can be a partial solution to this"
> which is not very helpful advice. That's a partial answer to my
> question #2 with zero response for
On Wed, Jul 16, 2014 at 10:56 AM, Jeremy wrote:
> Hey all,
> I had an idea for a new transaction type. The base idea is that it is
> matching on script hashes much like pay to script hash, but checks for one
> of N scripts.
This seems strictly less flexible and efficient than the Merkelized
Abstr
On Thu, Jul 17, 2014 at 2:35 PM, Kaz Wesley wrote:
> A node should be able to forget invs it has seen without invalidating what
> peers
> know about its known txes. To allow for this, a node assembles a bloom
> filter of
Another option would be to just guarantee to keep at least the last N
sent i
On Fri, Jul 18, 2014 at 5:54 PM, Emin Gün Sirer wrote:
> The problem being tackled here is very similar to "set reconciliation,"
> where
> peer A thinks that the set of transactions that should be in the block is
> S_A,
Most things I've seen working in this space are attempting to minimize
the da
On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine wrote:
>> 9. New signatures by the sender
>
> I'm not suggesting it be required, but it would be possible to
> mitigate this one by requiring that all signatures deterministically
> generate k per RFC6979. I'm using this in breadwallet.
Nope.
Your h
On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer wrote:
>
>> Most things I've seen working in this space are attempting to minimize
>> the data transfered. At least for the miner-interested case the round
>> complexity is much more important because a single RTT is enough to
>> basically send the w
On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine wrote:
> Well, you could always create a transaction with a different signature
> hash, say, by changing something trivial like nLockTime, or changing
> the order of inputs or outputs. Is that what you're talking about? Or
> is there some sophistry I'
On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore wrote:
> Hey all,
> I'm wondering if anyone can help explain to me tx
> 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...
A rather timely post. See the other thread on BIP0062. What you're
looking at is an example of a well-known-
On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd wrote:
> Might be worthwhile to also write an "Expectations for DNSSeed users"
> outlining what security properties the seeds actually have, and what
> kind of attacks are possible.
Agreed. I've seen some amount of use of dnsseeds which I would
consid
On Thu, Jul 24, 2014 at 7:35 PM, Aaron Voisine wrote:
> The upcoming release of breadwallet uses the height of the blockchain to
> enforce timed pin code lockouts for preventing an attacker from quickly
> making multiple pin guesses. This prevents them changing the devices system
> time to get aro
On Sun, Jul 27, 2014 at 7:12 PM, Jeremy wrote:
> Hey,
>
> There is a potential network exploit going on. In the last three days, a
> node (unnamed) came online and is now processing the most traffic out of any
> tor node -- and it is mostly plaintext Bitcoin traffic.
>
> http://torstatus.blutmagie
On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd wrote:
> Anyway, just goes to show that we need to implement better incoming
> connection limiting. gmaxwell has a good scheme with interactive
> proof-of-memory - where's your latest writeup?
Or its a complete snipe hunt, I'm unable to find any nodes w
On Sun, Jul 27, 2014 at 7:45 PM, Gregory Maxwell wrote:
> Or its a complete snipe hunt, I'm unable to find any nodes with it
> connected to them. Does anyone here have any?
[unimportant update] Turns out that my IPv4 nodes already have
iptables blocking of that subnet, presumably d
On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co wrote:
> These website list Tor nodes by bandwidth:
>
> http://torstatus.blutmagie.de/index.php
> https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc
>
> And the details reveal it's a port 8333 only exit node:
> http://torstatus.blutmagie.d
On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay wrote:
> I don't think Sybil attack is the right term for this.. there is only
> one IP address.. one "identity".
The bitcoin protocol is more or less identityless. It's using up lots
of network capacity, "number of sockets" is as pretty close as you
On Thu, Jul 31, 2014 at 1:47 PM, Kaz Wesley wrote:
> trip to request the missing tx; if we could somehow get the "What's
> the Difference" approach to effectively operate on full transactions
> instead
I explain how to do this on the network block coding page.
Given that you know the sizes and o
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley wrote:
>> the need to have transmitted the transaction list [..] first
>
> 32 bits per transaction is at least double the communication overhead
> of the simple approach, and only offers a bound on the probability of
> needing a round trip.
"(e.g. from
On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley wrote:
>> the FEC still lets you fill in the missing transactions without knowing in
>> advance all that will be missing.
>
> I don't see why we need to solve that problem, since the protocol
> already involves exchanging the information necessary to de
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock wrote:
> It would make more sense to introduce a new script opcode that pushes the
> current block height onto the operand stack. Then you could implement
> arbitrary logic about which blocks the transaction can be valid in. This
> would require th
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock wrote:
> I understand what you're saying, but I don't understand why it's a problem.
> Transactions shouldn't be considered "final" until a reasonable number of
> confirmations anyway, so the possibility that an "accepted" transaction could
> becom
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov wrote:
> Hi there,
> I'd like to start a discussion on periodic rotation of outbound connections.
> E.g. every 2-10 minutes an outbound connections is dropped and replaced
> by a new one.
Connection rotation would be fine for improving a node's kno
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille wrote:
> Yes, I believe peer rotation is useful, but not for privacy - just for
> improving the network's internal knowledge.
>
> I haven't looked at the implementation yet, but how I imagined it would be
> every X minutes you attempt a new outgoing
On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov
wrote:
> the same for a long time, an attacker which does not have any peers at all
> but just listens the Bitcoin network can link together differed BC addresses
> and learn the IP of the client.
I don't understand what you're talking about here;
On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov wrote:
> The attack I'm trying to address is described here:
> https://www.cryptolux.org/index.php/Bitcoin
> It was discussed here: https://bitcointalk.org/index.php?topic=632124.0
>
> It uses the following observation. Each NATed client connects t
On Mon, Aug 18, 2014 at 2:02 PM, Ivan Pustogarov wrote:
> For each neighbour, a Bitcoin peer keeps the history of addresses that
> it forwarded to the neighbour. If an address was already forwarded
> to a neighbour it is not retransmitted again.
Okay, sorry, I thought you were saying something el
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
wrote:
> If that's not acceptable, even using TLS with self-signed certificates
> would be an improvement.
TLS is a huge complex attack surface, any use of it requires an
additional dependency with a large amount of difficult to audit code.
TLS is t
On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik wrote:
> It would be nice if the issues and git repo for Bitcoin Core were not
> on such a centralized service as github, nice and convenient as it is.
>
> To that end, I note that Linux does its own git repo, and now requires
> 2FA:
> http://www.linux
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
wrote:
> While the rest of the 'net is busy deprecating HTTP and all other
> unencrypted transport methods, why is it(*) even a debate?
I think it's desirable (and you can go look in #bitcoin-dev logs for
me talking about it in the past)— but all of
On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes wrote:
> If a project cannot be organized enough to run its own hosting/web presense/
> counterintelligence/security that starts with installing an OS and patching
> kernels, then it is really not wise for me to trust my financial future to
> softw
On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy wrote:
> I want go give a bit of an outsiders perspective. I thoroughly understand
> the concepts of bitcoin and am a professional programmer, but have never
> taken the time to compile my own copy of bitcoin core.
>
> I have looked at the pull requests
On Tue, Aug 26, 2014 at 5:57 PM, Mem Wallet wrote:
>
> Does anyone see a value in a standardized PGP-style message,
> which would allow someone performing a bitcoin transaction to
> send signed encrypted messages using only public and private
> bitcoin keys ?
>
> I'd like to propose a signed encry
On Fri, Jul 18, 2014 at 8:14 AM, Pieter Wuille wrote:
> Hi all,
>
> I've sent a pull request to make a small change to BIP 62 (my
> anti-malleability proposal) which is still a draft; see:
> * https://github.com/bitcoin/bips/pull/90 (the request)
> * https://github.com/sipa/bips/blob/bip62up/bip-0
On Mon, Sep 15, 2014 at 3:51 PM, Matt Whitlock wrote:
> On Monday, 15 September 2014, at 5:10 pm, Thomas Zander wrote:
>> So for instance I start including a bitcoin public key in my email signature.
>> I don't sign the emails or anything like that, just to establish that
>> everyone
>> has my pu
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier wrote:
> Two draft information BIPs are attached.
I've pinged some people privately but also pinging the list… no
commentary on this proposal?
--
Meet PCI DSS 3.0 Complian
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock wrote:
> Is there a reason why we can't have the new opcode simply replace the top
> stack item with the block height of the txout being redeemed?
This would not be soft-forking compatible.
It also would be unsafe in that it would result in transact
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner wrote:
> I would like to share with you a vulnerability in the Bitcoin protocol I've
> been thinking of which might have impact on the future of Bitcoin. Please
> criticize it!
> The Freeze on Transaction Problem
I should point you to some of the tool
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell
> I should point you to some of the tools that have been discussed in
> the past which are potentially helpful here:
Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:
If transactions were using t
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón wrote:
> In any case, it is interesting to think about this things since mining
> subsidies will eventually disappear and then transaction fees will
> ALWAYS be higher than subsidies.
You can imagine that instead of subsidy Bitcoin came with a initial
s
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner wrote:
> Using the my previous terminology, automatic fee-sharing ("ORBS") is a
> solution to the freeze problem ("FRONT") but opens the windows to
> "CHAKIDO" double-spending. and CHAKIDO double-spending is a much worse
> problem than FRONT.
I'm not
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
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 Sat, Oct 11, 2014 at 11:34 PM, Pieter Wuille wrote:
> * Parallel block downloading (much faster sync on typical network
> connections).
"Much faster" is an understatement. Benchmarking here shows one hour
five minutes syncing to 295000. Old code isn't even at 25 after
7 hours.
(I'm us
On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille wrote:
> Hi all,
>
> while working on a BIP62 implementation I discovered yet another type
> of malleability: the interpretation of booleans.
>
> Any byte array with non-zero bytes in it (ignoring the highest bit of
> the last byte, which is the sign
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander wrote:
> What about rejecting a script where a bool is not explicitly zero or one?
I believe this is what he actually meant.
--
Comprehensive Server Monitoring with Site24x7
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir wrote:
> Hello,
>
> I'm trying to create a bit of process around the
> https://github.com/bitcoin/bips repository.
>
> A) Currently a lot of pulls are open for various BIPs and it is not
> clear who should comment on them, or who decides on changes to be
>
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding wrote:
> Matt,
>
> You're right, thanks. Without double-spend relay, miner won't know that
> some txes conflict with anything.
Even with that, the miner cannot tell, his only safe option is to
include no transactions at all.
Consider a malicious mine
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
wrote:
>
> On Oct 25, 2014 9:19 PM, "Gavin Andresen" wrote:
> > We had a halving, and it was a non-event.
> > Is there some reason to believe next time will be different?
>
> In november 2008 bitcoin was a much younger ecosystem,
Or very ol
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste
wrote:
> The fact that a topic was brought up many times since a long time,
> does not mean it is not relevant.
I am not saying that it is "not relevant", I'm saying the discussion
is pointless:
No new information has arrived since the very
On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell wrote:
> Hi all,
>
> I've been toying with an algorithm to place a ceiling on
> confirmation latency by allowing weaker blocks after a certain time.
> Hope this isn't noise, but thought someone must have considered this
> before, or know of f
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd wrote:
> BIP62 does make life easier for wallet authors as they don't have to
> deal with malleability - maybe! -
Yes, I agree for most contract purposes CTLV is what you want to be
using, instead of refund transactions beyond being more clearly
correct
Some initial comments...
Tying in the protocol changes is really confusing and the fact that
they seem to be required out the gates would seemingly make this much
harder to deploy. Is there a need to do that? Why can't the p2p part
be entirely separate from the comitted data?
On Mon, Nov 10, 20
> Since this attack vector has been discussed, I started making some
> measurements on how effective it is to connect to Bitcoin using Tor,
> and I found that the number of connections dropping to near-zero is
> a situation which occurs rather frequently, which suggests that there
> is still room t
On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs wrote:
> I might be mistaken, but it seems to me this paper discusses unintended ways
> of obtaining the IP addresses of clients involved in transactions on the
> core Bitcoin network.
You're mistaken. :)
If a node is used exclusively via tor it effect
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore wrote:
> Heya,
>
> I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
> thought it might make more sense to instead have a OP_CHECKLOCKTIME which
> would simply push an OP_TRUE or OP_FALSE onto the stack?
Updating the stack is no
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs wrote:
> That's what I was trying to say... The researchers are deanonymizing
> transactions from non-Tor connected hosts. So why are we talking about Tor
> limitations in response to this? Shouldn't we be discussing how to address
> the issues in Bitco
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
wrote:
>> This breaks existing invariants and would make the coins potentially less
>> fungible because they wouldn't be reorg safe.
>
> I'm not sure coins are ever reorg safe. All it takes is a double spend in
> the history of your coins for them
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd wrote:
[snip]
> Pull-req #4890², specifically commit c7829ea7, changed the
This change was authored more than three months ago and merged more
than two months ago.
[And also, AFAICT, prior to you authoring BIP65]
I didn't participate in that pull-req,
On Sat, Dec 20, 2014 at 11:14 AM, Jeremy Spilman wrote:
>> are dnsseeds being blocked
> ostensibly because they are acting as dyanamic DNS infrastructure for
> malware sites?
Pretty much appears to be the case. In every instance it appears to be
automated. This predates the msft no-ip.com stuff.
On Wed, Dec 24, 2014 at 5:08 PM, Will Bickford wrote:
> A tally from August indicated that I may need to slog through 280,000 lines
You're counting 170kloc of machine generated code with the translation
strings there.
The top level (/src) and libconsensus are only about 36kloc. This is
small eno
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input to be added (only a
> pseudo-input).
> This is a ha
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
wrote:
> Slight off-topic:
> That looks like an abuse of the VM. Even P2SH is an abuse of the VM.
> Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a
> simple change that goes along the lines of Satoshi's original design.
> Bitcoi
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll wrote:
> Dear all,
>
> I've been looking at atomic cross-chain trading (
> https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
> Bitcoin and Dogecoin blockchains, and have a mostly functional
> prototype. However as it stands if the refun
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll wrote:
> Grabbing a simple test case:
> https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
> - that won't lock until 0028 UTC on the 5th.
>
> I've tried closing the wallet, moving the wallet.dat file out of the
>
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell wrote:
> Can you send me the actual raw transaction (that site doesn't appear
> have a way to get it, only some cooked json output; which doesn't
> include the sequence number).
Nevermind, I guess. I think I figured out your pro
On Sun, Jan 4, 2015 at 6:11 PM, Ross Nicoll wrote:
> Ah, thanks for that.
>
> I'll try Peter's patch for testnet tomorrow, sounds like it should fix
> this for my use case.
Thanks for presenting your solution as code in any case. In spite of
the fact that I gave it a crappy read this time, it rea
On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn wrote:
>> A limitation on most existing micropayment channel ideas is that payments
>> can only flow in one direction.
> It's worth noting that the original protocol as designed by Satoshi did not
> have this limitation. It has evolved this way because of
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn wrote:
> Additionally, there is a school of thought that says Bitcoin must work even
> if lots of miners are malicious and willing to break arbitrary things in
> order to try and get more money. I don't think Bitcoin can really be a
This being unsafe doe
OpenSSL 1.0.0p / 1.0.1k was recently released and is being
pushed out by various operating system maintainers. My review
determined that this update is incompatible with the Bitcoin
system and could lead to consensus forks.
Bitcoin Core released binaries from Bitcoin.org are unaffected,
as are an
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner wrote:
> Unfortunately, it seems that there was no soft-fork way to achieve this
> benefit, at least not one that had favorable properties. Most of the
> soft-fork variations of it required the coins being spent to have been
> originated in a special w
On Fri, Jan 23, 2015 at 4:18 PM, slush wrote:
> Can you send me any reference about this? Of course if that solves the
> problem, hard fork would not be necessary anymore. I'm just not aware of
> any.
Sure; will aggregate up the citations when I'm not travling later today.
> To sign transaction
On Fri, Jan 23, 2015 at 5:40 PM, slush wrote:
> Yes, the step you're missing is "and build the table". Dynamic memory
> allocation is something you want to avoid, as well as any artifical
> restrictions to number of inputs or outputs. Current solution is slow, but
> there's really no limitation on
On Sun, Jan 25, 2015 at 2:34 PM, Pieter Wuille wrote:
> * Add it to the softfork now, and be done with it.
Initially I was of the opinion that we couldn't do that, because
soft-forks which hit transactions many nodes would relay+mine creates
a forking risk... but with the realization that imbalan
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille wrote:
> On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille
> wrote:
>> I therefore propose a softfork to make non-DER signatures illegal
>> (they've been non-standard since v0.8.0). A draft BIP text can be
>> found on:
>>
>> https://gist.github.com
On Sun, Feb 1, 2015 at 8:08 PM, xor wrote:
> Why is that?
Because Binaries on Bitcoin.org have always been unaffected by the
issue 0.9.4 was released to address.
> Also, is it correct that there wasn't a release candidate before the release?
> Sounds dangerous to me.
The changes were tried firs
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille wrote:
> The much simpler alternative is just adding this to BIP66's DERSIG
> right now, which is a one-line change that's obviously softforking. Is
> anyone opposed to doing so at this stage?
Thats my preference.
---
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
wrote:
> Hi there,
>
> traditionally, the Bitcoin client strives to hide which output
> addresses are change addresses going back to the payer. However,
> especially with today's dynamically calculated miner fees, this
> may often be ineffective:
>
> A
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn wrote:
> history. Lots of miners have dropped out due to hardware obsolescence, yet
> massive double spending hasn't happened.
How many thousands of BTC must be stolen by miners before you'd agree
that it has, in fact, happened?
(https://bitcointalk.org
On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn wrote:
> And then what? So you know the block matches. But with reasonable FP rates
> every block will match at least a few transactions (this is already the case
This approach needs a filter set with a lower FP rate. It doesn't
depend on having a high
1 - 100 of 454 matches
Mail list logo
