On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach m...@monetize.io wrote:
I don't think such a pull request would be accepted. The point was to
minimize impact to the block chain. Each extras txout adds 9 bytes
minimum, with zero benefit over serializing the data together in a
single
I've noticed some folks struggling to attach labels to their yet to be
numbered BIPs.
I'd recommend people call them draft-main author name-what it
does like draft-maxwell-coinburning in the style of pre-WG IETF
drafts.
On Mon, May 12, 2014 at 10:01 AM, Matt Whitlock b...@mattwhitlock.name 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
On Thu, May 15, 2014 at 4:50 AM, Andreas Schildbach
andr...@schildbach.de 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
On Sat, May 17, 2014 at 9:07 AM, Chris Pacia ctpa...@gmail.com 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
On Mon, May 19, 2014 at 8:09 AM, Mike Hearn m...@plan99.net 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
On Mon, May 19, 2014 at 1:01 PM, Justus Ranvier justusranv...@gmail.com 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
On Wed, May 21, 2014 at 1:30 PM, Mark Friedenbach m...@monetize.io 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
On Fri, May 23, 2014 at 9:48 AM, Kyle Jerviss bitcoin-de...@jerviss.org 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
On Fri, May 23, 2014 at 8:57 PM, Ashley Holman dsc...@gmail.com 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
On Sat, May 24, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com 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
On Sun, May 25, 2014 at 2:36 AM, Mike Hearn m...@plan99.net 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
On Fri, May 30, 2014 at 8:40 AM, Andreas Schildbach
andr...@schildbach.de 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
On Mon, Jun 2, 2014 at 12:39 AM, Wladimir laa...@gmail.com 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
On Fri, Jun 6, 2014 at 1:48 AM, Adam Back a...@cypherspace.org 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
On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd p...@petertodd.org 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
On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd p...@petertodd.org 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
On Mon, Jun 9, 2014 at 11:13 AM, Richard Moore m...@ricmoo.com 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
On Tue, Jun 17, 2014 at 2:14 PM, Odinn Cyberguerrilla
odinn.cyberguerri...@riseup.net 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
On Fri, Jul 4, 2014 at 3:27 AM, Andy Parkins andypark...@gmail.com 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.
On Wed, Jul 16, 2014 at 10:56 AM, Jeremy jlru...@mit.edu 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
On Thu, Jul 17, 2014 at 2:35 PM, Kaz Wesley kezi...@gmail.com 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
On Fri, Jul 18, 2014 at 5:54 PM, Emin Gün Sirer el33th4...@gmail.com 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
On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine vois...@gmail.com 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.
On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer el33th4...@gmail.com 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
On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine vois...@gmail.com 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
On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore m...@ricmoo.com 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
On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd p...@petertodd.org 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
On Thu, Jul 24, 2014 at 7:35 PM, Aaron Voisine vois...@gmail.com 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
On Sun, Jul 27, 2014 at 7:12 PM, Jeremy jlru...@mit.edu 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.
On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd p...@petertodd.org 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
On Sun, Jul 27, 2014 at 7:45 PM, Gregory Maxwell gmaxw...@gmail.com 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
On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co m...@bitwatch.co wrote:
These website list Tor nodes by bandwidth:
http://torstatus.blutmagie.de/index.php
https://torstatus.rueckgr.at/index.php?SR=BandwidthSO=Desc
And the details reveal it's a port 8333 only exit node:
On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay rob...@mckay.com 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
On Thu, Jul 31, 2014 at 1:47 PM, Kaz Wesley kezi...@gmail.com 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
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley kezi...@gmail.com 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.
On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley kezi...@gmail.com 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
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock b...@mattwhitlock.name 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
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock b...@mattwhitlock.name 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
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov ivan.pustoga...@uni.lu 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
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille pieter.wui...@gmail.com 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
On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov
ivan.pustoga...@uni.lu 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
On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov ivan.pustoga...@uni.lu 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
On Mon, Aug 18, 2014 at 2:02 PM, Ivan Pustogarov ivan.pustoga...@uni.lu 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
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
justusranv...@riseup.net 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
On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik jgar...@bitpay.com 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:
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
justusranv...@riseup.net 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
On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes ho...@hozed.org 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
On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy prab...@gmail.com 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
On Fri, Jul 18, 2014 at 8:14 AM, Pieter Wuille pieter.wui...@gmail.com 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)
*
On Mon, Sep 15, 2014 at 3:51 PM, Matt Whitlock b...@mattwhitlock.name 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
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier jus...@monetas.net wrote:
Two draft information BIPs are attached.
I've pinged some people privately but also pinging the list… no
commentary on this proposal?
--
Meet
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock b...@mattwhitlock.name 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
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner sergioler...@certimix.com 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
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell gmaxw...@gmail.com
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
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón jti...@blockstream.io 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
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com 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
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org 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
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd p...@petertodd.org 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
On Sat, Oct 11, 2014 at 11:34 PM, Pieter Wuille pieter.wui...@gmail.com 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
On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille pieter.wui...@gmail.com 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,
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander tho...@thomaszander.se 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
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir laa...@gmail.com 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
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding t...@thinlink.com 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
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
ferdinando.ametr...@gmail.com wrote:
On Oct 25, 2014 9:19 PM, Gavin Andresen gavinandre...@gmail.com 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
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste
jeremie...@gmail.com 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
On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell ru...@rustcorp.com.au 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
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd p...@petertodd.org 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
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,
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 to
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore m...@ricmoo.com 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
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs mister...@gmail.com 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
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
flavien.char...@coinprism.com 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
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd p...@petertodd.org 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
On Sat, Dec 20, 2014 at 11:14 AM, Jeremy Spilman jer...@taplink.co 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
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
sergioler...@certimix.com 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
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
sergioler...@certimix.com 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
On Fri, Jan 23, 2015 at 4:18 PM, slush sl...@centrum.cz 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
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com
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
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com 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
cryptocurrenc...@quidecco.de 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
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn m...@plan99.net 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?
On Sun, Feb 1, 2015 at 8:08 PM, xor x...@freenetproject.org 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
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
On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn m...@plan99.net 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
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn m...@plan99.net 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
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk 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
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll j...@jrn.me.uk 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
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com 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 problem
On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin m...@thomaskerin.io wrote:
I used BIP0090 as a place-holder, but I would like to request a BIP number
for this now.
We have had repeated problems in the past with people working on and
circulating prior draft proposals squatting on each others
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
ricardojdfil...@gmail.com wrote:
i guess you look at the glass half full :)
even though what you say is true, we should aim for wallets not to
require those instructions, by standardizing these things in BIPs.
let's hope bitcoin doesn't fail in
On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong pindar.w...@gmail.com wrote:
Perhaps at some point consider introducing something akin to a
'Bitcoin-Draft' (BD) status with some autoexpiry period?
I understand that the Internet Engineering Task Force (IETF) has the
concept of 'Internet Drafts
On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@niftybox.net wrote:
That said, I do agree that mnemonic phrases should be portable, and find
it unfortunate that the ecosystem is failing to standardize on phrase
handling.
The fact remains that there are several apparently unresolvable
This seems overly complicated to me, unless I'm missing something.
Instead, I think you should just give the server the master pubkey P
only without the chaincode.
Then when you transact you generate the address in whatever manner you
like and tell the server the scalar value iL which the user
On Thu, Mar 12, 2015 at 2:41 AM, devrandom c1.sf-bitc...@niftybox.net wrote:
I think there are some important advantages to not being forced to use
the old wallet to send coins when switching wallets. The three I can
think of right now are: maintaining transaction history,
Just loading a key
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle thyshiz...@outlook.com wrote:
Yes I agree, also there is talks about a government body I know of warming
to bitcoin by issuing addresses for use by a business and then all
transactions can be tracked for that business entity. This is one proposal I
It would appear that the Bitcoin Foundation has decided that their
next two seats would be decided by miners. (More information
available at:
https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453
)
Unfortunately, they seem to have not provided the software
On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn m...@plan99.net 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
On Fri, Feb 20, 2015 at 5:59 PM, Adam Back a...@cypherspace.org wrote:
So now they ask a full node for merkle paths + transactions for the
addresses from the UTXO set from the block(s) that it was found in.
Use of the words UTXO set here is probably confusing people as it's
likely to make
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding t...@thinlink.com wrote:
I addressed that by limiting the duplicate check to an X-block segment. X
is hard-coded in this simple scheme (X=144 = 1-day addresses). You
could picture a selectable expiration duration too.
If its to be heuristic in
201 - 300 of 322 matches
Mail list logo
