That's great! I'm all for more wallets, especially user friendly UIs.
However being based on bitcoind means it will take a very long time to
synchronize for new users. We know a lot of users drop out. The best fix
for this is SPV mode. Do you have any plans in this direction?
So far, the only
On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:
That's great! I'm all for more wallets, especially user friendly UIs.
However being based on bitcoind means it will take a very long time to
synchronize for new users. We know a lot of users drop out. The best fix
for this is SPV mode. Do
bitcoinj is ideal for our purposes. How can we assist or
otherwise accelerate such an effort?
-w
On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:
That's great! I'm all for more wallets, especially user friendly UIs.
However being based on bitcoind means it will take a very long time
in on
there to
close
issues down as well as me.
On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote:
Sounds like we have consensus, Saivann, shall we do it?
I'm also going to ask Theymos again to relax the newbie
restrictions
That's true - we could serve new users off our own servers and auto updates
off SF.net mirrors, potentially.
On Tue, Jul 9, 2013 at 4:57 PM, Daniel F nanot...@gmail.com wrote:
on 07/09/2013 10:28 AM Mike Hearn said the following:
SourceForge has a horrible UI and blocks some countries
That's good to know. Still, at the moment we'd need to dramatically
increase the download size and increase Bitcoin usage by 10x to hit our
limits. It'd be a good problem to have.
On Tue, Jul 9, 2013 at 5:51 PM, Johnathan Corgan
johnat...@corganlabs.comwrote:
On 07/09/2013 08:32 AM, Nick
Arguments in favor of retaining Bitcoin-Qt/bitcoind default:
* More field experience, code review and testing on desktop than others
I'm hoping that if we start promoting alternative wallets their dev
communities will get larger. Most bitcoinj code is peer reviewed, but
not to the same extent
AM, Mike Hearn m...@plan99.net wrote:
I see some of the the other things that were concerning for me at the
time are still uncorrected though, e.g. no proxy support (so users
can't follow our recommended best practices of using it with Tor),
Yeah. That's not the primary privacy issue
Indeed, and for a higher level answer, see here:
https://en.bitcoin.it/wiki/Contracts
On Fri, Jun 21, 2013 at 6:03 AM, Patrick Strateman
patr...@intersango.comwrote:
It's well answered by this stack exchange question.
http://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence
that fRelayTxes is part of the protocol, the version number should be
upgraded to reflect this fact.
--
*From:* Mike Hearn m...@plan99.net
*To:* Paul Lyon pml...@hotmail.ca
*Cc:* Turkey Breast turkeybre...@yahoo.com;
bitcoin-development@lists.sourceforge.net
Sure but why not do that when there's an actual new field to add? Does
anyone have a proposal for a feature that needs a new version field at the
moment? There's no point changing the protocol now unless there's actually
a new field to add.
Anyway I still don't see why anyone cares about this
is not present.
Your argument is that this complexity is already there so why not preserve
it. I think eliminating complexity (that has no benefit) strengthens the
system.
*Tamás Blummer*
http://bitsofproof.com
http://bitsofproof.com/
On 20.06.2013, at 09:36, Mike Hearn m...@plan99.net
their code anyway.
So I have a slight preference for keeping things the way they are, it keeps
things flexible for future and costs nothing.
On Thu, Jun 20, 2013 at 11:06 AM, Pieter Wuille pieter.wui...@gmail.comwrote:
On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:
Sure but why
optional to required now anyway - that's a behaviour change. It'd be good
to enforce that. I see this as a bug.
--
*From:* Mike Hearn m...@plan99.net
*To:* Pieter Wuille pieter.wui...@gmail.com
*Cc:* Bitcoin Dev bitcoin-development@lists.sourceforge.net; Tamas
Blummer
- that's a behaviour change. It'd be good
to enforce that. I see this as a bug.
--
*From:* Mike Hearn m...@plan99.net
*To:* Pieter Wuille pieter.wui...@gmail.com
*Cc:* Bitcoin Dev bitcoin-development@lists.sourceforge.net; Tamas
Blummer ta...@bitsofproof.com
*Sent
implementations to have an unclear behaviour
that depends on some magic from one implementation.
--
*From:* Mike Hearn m...@plan99.net
*To:* Turkey Breast turkeybre...@yahoo.com
*Cc:* bitcoin-development@lists.sourceforge.net
bitcoin-development
horribly violating
any mailing list etiquette.
*From:* Mike Hearn
*Sent:* Wednesday, June 19, 2013 7:43 AM
*To:* Turkey Breast
*Cc:* bitcoin-development@lists.sourceforge.net
Bitcoin-Qt on master does send it now although it doesn't affect anything,
but as old pre-filtering
It's not a bug (although there was recently a change to make bitcoind/qt
always send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have always
been variable length. There's nothing inherent in the Bitcoin protocol that
says all messages are fixed length,
I'm pleased to announce the release of bitcoinj 0.9, a Java library for
working with the Bitcoin protocol. Both simplified and full verification
are supported. BitcoinJ has been used to create everything from end-user
wallet apps to network crawlers to SatoshiDice.
To get bitcoinj 0.9, check out
Bitcoinj already has such chain id's and we use standard Java style reverse
DNS names: org.bitcoin.main, etc. If we want a more global naming system
that seems like a good compromise between uniqueness and readability.
On 20 May 2013 19:45, Jeff Garzik jgar...@exmulti.com wrote:
On Mon, May 20,
Conceptually it sounds a lot like ZeroCoin (not in implementation)?
I'm not really convinced miner cartels that try to exclude transactions are
likely to be a big deal, but such schemes could I suppose be kept in a back
pocket in case one day I'm proven wrong.
On Wed, May 15, 2013 at 6:39 PM,
2038 issues only apply to use of signed timestamps, I thought we treat
this field as unsigned? Is it really a big deal?
On Thu, May 9, 2013 at 1:12 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Wed, May 08, 2013 at 10:42:44PM -0400, Peter Todd wrote:
Ah, shoot, I just realized we both got
You mean scam you with a zero-conf transaction that hasn't actually been
broadcast?
Yeah. Or just scam you at all. It's hard to imagine an organisation as
a big as a mobile carrier engaging in financial scamming (roaming fees
excepted).
I've said this before, but I think it's worth repeating.
You are welcome to optimise P2P addr broadcasts or develop better bootstrap
mechanisms.
On Sun, May 5, 2013 at 3:12 PM, John Dillon
john.dillon...@googlemail.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sorry I should have used the word bootstrapping there rather than
It's expected to be there, yes.
On Mon, May 6, 2013 at 9:56 AM, Addy Yeow ayeo...@gmail.com wrote:
From https://en.bitcoin.it/wiki/Protocol_specification#version, is the
relay field (bool/1 byte) required in all version packets coming from
client with protocol version = 70001?
I've noticed on my Android phone how it often takes quite awhile to find
a peer that will actually accept an incoming connection, which isn't
surprising really: why should a regular node care about responding to
SPV nodes quickly?
I haven't seen that - remote nodes don't have any special
Speaking of, off-topic for this discussion, but in the future
node-to-node communicate should be encrypted and signed
Yes, I'd like to do this. The threat isn't really ISPs which are
mostly trustable (the worst they normally do outside of places like
China is dick about with ads), the big
Yes, I like that better than broadcasting the exact height starting at
which you serve (though I would put that information immediately in the
version announcement). I don't think we can rely on the addr broadcasting
mechanism for fast information exchange anyway. One more problem with this:
If you're going to take a step like that, the current-chain-height
should be rounded off, perhaps to some number of bits, or you'll allow
DNS caching to be defeated.
Don't the seeds already set small times? I'm not sure we want these
responses to be cacheable, otherwise there's a risk of a
Backing up a step, I'm not sure what the threat model is for signing the
refund address? The same process that's signing the transaction is doing an
HTTPS POST with the refund address.
It's a real threat, albeit an exotic one. The threat model is a malware
compromised host, with a wallet
I'd imagined that nodes would be able to pick their own ranges to keep
rather than have fixed chosen intervals. Everything or two weeks is
rather restrictive - presumably node operators are constrained by physical
disk space, which means the quantity of blocks they would want to keep can
vary with
(for background: I did a lot of the design work with Gavin on the payment
protocol and suggested/prototyped using x.509 in the way we do).
So, I'm not a fan of weird hacks involving non-existent domain names.
There's a clean way to implement this and we decided to punt on it for v1
in order to
Chaining a custom cert onto the end doesn't work, at least not if your
end is the SSL cert. Chaining it to the SSL cert defeats the OP's
intention of cold signing, as the SSL private key is usually kept
online, therefore can't be used to sign a pubkey that is supposed to
stay offline.
What
That's a pointless goal to try and solve right now, because the SSL
PKI cannot handle compromised web servers and so neither can we (with
v1 of the payments spec).
I don't think the OP intended to solve it right now, i.e. in v1.
He differentiated between most trusted and less trusted
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell mcaldw...@swipeclock.comwrote:
I am not sure if my replies hit the list. If not, can anyone who sees this
help?
In the past, I have pre signed (with PGP) large batches of Bitcoin
addresses for distribution on my server. This way, even in the
HTML5 allows web apps to register themselves for handling URI schemes, such
as the bitcoin: URI that is already in use and being extended as part of
the payment protocol.
The bad news is that for security reasons there is a whitelist of
acceptable schemes in the spec:
Yes, this is an excellent observation. Thanks Jeremy and Peter. It's much
less general than full blown tx replacement+lock times, but for the case of
a channel between two people that only ever increases in one direction, it
can work. Thanks. I will try implementing this myself for testing on the
When did I say DoS was unimportant? I just wrote a giant email explaining
how it can be resolved.
I think it's worth pointing out that Bitcoin was launched with no DoS
protection at all, and it's still here. There are still obvious DoS bugs
being fixed with every release. So yes, it's important
An attack still shuts down useful tx replacement though. For instance in
the adjusting payments example an attacker sets up a legit adjusting
payment channel, does a bunch of adjustments, and then launches their
attack. They broadcast enough adjustments that their adjustment session
looks
On Thu, Apr 18, 2013 at 11:28 AM, Mike Hearn m...@plan99.net wrote:
With the sipaspeed patches it seems ECDSA can be processed on modern cores
at something like 20,000 signatures per second. So it'd take a bit over 4
seconds to process all of them (cpu time).
Sorry brainfart, s/cores/cpus
...and actually, that's not a problem if the defender is online, because
they can just broadcast the highest sequence numbered tx, which blocks
further broadcasts by the attacker.
Good point - transactions can be ordered by highest version seen before
they're signature checked. Even without
Indeed, as I mentioned in my first mail, nodes can be told how much
bandwidth they're allowed to use and then prioritize within that, so I
don't see any way convergence can fail. And regardless, I used 10mbit for
the calculations, that isn't exactly unlimited. My home internet connection
is better
Or are you talking about some sort of new decentralized high frequency
trading system that is self-matching and self-clearing? (I'd be very
interested in hearing more if this is the case).
I'm using the term high frequency trading because Satoshi did. Like the
way he used the word contract it
This was previously discussed on the forums a bunch of times, but in
particular here:
https://bitcointalk.org/index.php?topic=91732.0
BTW, I don't think all this has to be solved to re-activate replacement on
testnet. It's useful for people to be able to develop apps that use this
feature,
OK, as the start of that conversation is now on the list, I might as well
post the other thoughts we had. Or at least that I had :)
It's tempting to see this kind of abuse through the lens of fees, because
we only have a few hammers and so everything looks like a kind of nail. The
problem is the
However, there should be some metrics and heuristics that take care of
this problem. Notably the dev consensus (sans you, Mike :)) seems to
be that uneconomical outputs should be made non-standard.
I think that patch is ok as it doesn't really have any fixed concept of
what is uneconomical.
I'm happy to announce the release of bitcoinj 0.8, a Java library for
writing Bitcoin applications. Both simplified and full verification are
supported. BitcoinJ has been used to create everything from end-user wallet
apps to network crawlers to SatoshiDice.
To get bitcoinj 0.8, check out our
It'd help to know how the signatures are invalid.
On Sun, Apr 7, 2013 at 5:34 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
(cross-post from bitcointalk.org)
Hello all,
as some may know, Bitcoin uses DER-encoded signatures in its transactions.
However, OpenSSL (which is used to verify
In bitcoinj we desperately need integration tests to exercise the wallet
code, and I think if it was done well the tests would be applicable to
bitcoind as well. There have been a series of bugs in bitcoinj that boiled
down to the unit tests were not realistic enough, either because they
stopped
51% isn't a magic number - it's possible to do double spends against
confirmed transactions before that. If Michael wanted to do so, with the
current setup he could, and that's obviously rather different to how
Satoshi envisioned mining working.
However, you're somewhat right in the sense that
My general hope/vague plan for bitcoinj based wallets is to get them all on
to automatic updates with threshold signatures. Combined with regular
audits of the initial downloads for new users, that should give a pretty
safe result that is immune to a developer going rogue.
On Wed, Apr 3, 2013 at
By the way, I have a download of the Bitcoin-Qt client and signature
verification running in a cron job.
On Thu, Apr 4, 2013 at 10:11 AM, Mike Hearn m...@plan99.net wrote:
My general hope/vague plan for bitcoinj based wallets is to get them all
on to automatic updates with threshold
Just so we're all on the same page, can someone confirm my
understanding - are any of the following statements untrue?
BDB ran out of locks.
However, only on some 0.7 nodes. Others, perhaps nodes using different
flags, managed it.
We have processed 1mb sized blocks on the testnet.
Therefore it
However, most nodes are not running in such a loop today. Probably
almost no nodes are.
I suppose you could consider mass node death to be more benign than a
hard fork, but both are pretty damn serious and warrant immediate
action. Otherwise we're going to see the number of nodes drop sharply
We just saw a hard-fork happen because we ran into previously unknown
scaling issues with the current codebase.
Technically, it with the previous codebase ;)
--
Symantec Endpoint Protection 12 positioned as A LEADER in
I'm not even sure I'd say the upgrade went wrong. The problem if
anything is the upgrade didn't happen fast enough. If we had run out
of block space a few months from now, or if miners/merchants/exchanges
had upgraded faster, it'd have made more sense to just roll forward
and tolerate the loss of
Why does demurrage even still come up? The base rules of Bitcoin will
not be changing in such a fundamental way.
With regards to trying to minimize the size of the UTXO set, this
again feels like a solution in search of a problem. Even with SD
abusing micropayments as messages, it's only a few
This would be bloating UTXO data at a speed of 52 GB/year. That's a very
big memory leak. And this is just the unspendable outputs.
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs
that never get spent are not in the working set by definition, after a
while they just end
To summarize your post - it's another go at arguing for strongly
limited block sizes, this time on the grounds that large blocks make
it easier for $AUTHORITY to censor transactions? Is that right?
--
Symantec Endpoint
As an aside, there's a paper coming out in perhaps a few months that
describes a new way to provide Chaum-style privacy integrated with
Bitcoin, but without the use of blinding and without any need for
banks. It's quite smart, I was reviewing the paper this week.
Unfortunately the technique is too
:
On Wed, Feb 6, 2013 at 8:33 AM, Mike Hearn m...@plan99.net wrote:
Can somebody please unlock the BIP wiki page? I don't know why it was
locked
but it's stale.
I asked for permissions to unlock it but haven't heard back— will prod
I'm pleased to announce the release of version 0.7 of the bitcoinj Java
library for working with Bitcoin. Bitcoinj forms the foundation of
MultiBit, Bitcoin Wallet for Android, SatoshiDice and more.
To get bitcoinj 0.7, check out our source from git and then run *git reset
--hard a9bd8631b904*.
So what exactly was the OP_RETURN bug anyway? I know it has something to
do with not executing the scriptSig and scriptPubKey separately
(https://bitcointalk.org/index.php?topic=58579.msg691432#msg691432) but
commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged.
It was
Can somebody please unlock the BIP wiki page? I don't know why it was
locked but it's stale.
On Wed, Jan 30, 2013 at 12:13 PM, Mike Hearn m...@plan99.net wrote:
Sorry, to clarify, these are test builds available here:
https://code.google.com/p/bitcoin-wallet/downloads/detail?name=bitcoin
, as otherwise there's a
risk that 0.7 snapshot nodes will get overloaded.
On Wed, Jan 30, 2013 at 12:09 PM, Mike Hearn m...@plan99.net wrote:
Andreas has uploaded Android builds that use the new bloom filtering and
peer selection code (also, dependency analysis of transactions).
The performance gain
algorithmic change I would like to
make to the way the hash function is computed really quick before it
gets merged, I'll have that finished up by the end of today.
Matt
On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:
Matts latest code has been tested by Andreas and seems to work
Matts latest code has been tested by Andreas and seems to work
correctly. He had to extend the client a bit to refresh the filter
every 25k blocks because even with the extra flag, eventually the
filter degrades into uselessness, but it did still improve the
situation quite a bit.
Because it's
Oh, one last stat - syncing the entire chain with a wallet containing
two keys and a 0.0001 FP rate (one or two FPs every 5 blocks or so)
resulted in a download of about 46mb of data.
On Fri, Jan 11, 2013 at 3:11 PM, Mike Hearn m...@plan99.net wrote:
I did some very rough initial performance
Here's a quick update on where we're up to.
Thanks to Matts excellent work, I was able to test his bitcoinj and
bitcoin-qt work together today. There are a few minor tweaks needed,
but I feel like we're maybe a week away from having all the code in a
mergeable state. Here is the remaining work:
++, which perhaps ends up making
gcc stricter than it's supposed to be.
On Thu, Nov 29, 2012 at 8:34 PM, Mike Hearn m...@plan99.net wrote:
I found that the problem is the version of the Qt SDK I used didn't
like the new MacOS version. Re-installing Qt fixed it.
On Mon, Nov 26, 2012 at 4:05 PM
Thanks for the thoughts. For those who don't know, Stephen works for BitPay.
My first observation is that the proposal is too heavily oriented around a
merchant/customer interaction.
The term merchant is just being used to mean the entity requesting
the payment. I'm hopeful that in future
OK. I want to keep the signature field required, though, so how about:
signature: digital signature over a protocol buffer serialized variation of
the SignedPaymentRequest message where signature is a zero-byte array and
fields are serialized in numerical order (all current protocol buffer
mitigations into something like this, for the
same reason HTML doesn't impose a maximum page size. It's in the
message builders interest to ensure it gets read by all users.
Crashing their clients doesn't achieve anything as long as the crash
isn't exploitable.
On Fri, Dec 7, 2012 at 11:45 AM, Mike
yeah... I had similar thoughts on what to do if some Outputs specify an
amount and others don't. I'm still waffling on whether or not I like
allowing repeated Outputs; a single Output would make the spec a fair bit
simpler
Yes, but at the cost of privacy. Generators of payment requests always
Escrow/multisig is complicated enough to wait for another day. But
certainly having a payment protocol is an important step towards it
On 6 Dec 2012 07:32, Andreas Petersson andr...@petersson.at wrote:
During/before the Payment Request there should be a method to exchange
the public keys to be
Re: the newest spec. Rather than make the signature over the
concatenation of, why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must be
I was under the impression that connectedness was the real metric of
concern
I think the real thing we need full nodes for is sockets where by
socket I mean resources needed to serve another node.
Last year we actually ran out of sockets and it took forever for new
nodes to connect because so
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
I think that's OK. However, you
It sounds to me that you're insisting that you're asking people who
oppose degrading our recommendations to commit to a costly rushed
development timeline. I think this is a false choice.
Hardly. I don't have any particular timeline in mind. But I disagree
we have forever. New ideas have a
The main source for these 1 Satoshi payouts is Sahtoshi Dice.
Because people are making 1 satoshi bets, or is this part of their
messaging system?
Pieter is right, getting consensus behind your proposal is too hard
and it's not likely to ever happen (I wouldn't support it, for one).
Outputs
It's part of their messaging system. Every losing play results in a
new 1e-8 output being created.
Every losing play? That's ... not excellent.
Well, this why the payment protocol spec has a way for merchants to
reply to customers with text instead of outputs.
Perhaps it could be improved by cleaning up dust from any address by default
(not just ones already included in the tx), with the option for the user to
disable that behavior. After all, anonymity was never a core feature of the
network
It's cool that Armory already does this. I never had
I'd still like to understand the rationale for having the merchant
broadcast the transaction
There are several reasons for this:
1) P2P network sockets are a limited resource and bringing up
connections to the network, whilst somewhat fast today, is not
guaranteed to be fast in future. Passing
I found that the problem is the version of the Qt SDK I used didn't
like the new MacOS version. Re-installing Qt fixed it.
On Mon, Nov 26, 2012 at 4:05 PM, Mike Hearn m...@plan99.net wrote:
It appears that something about Boost doesn't play nicely with the default
build instructions (possibly
On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager grona...@ceptacle.com wrote:
* What if the SignedReceipt is not received AND the transactions IS posted on
the p2p.
I think this is a problem with confusing terminology rather then the
spec itself.
The original formulation had a receipt being
That hash would then be reported via some secure channel outside of bitcoin's
domain.
OK, I see. I guess that could be a reasonable fallback for the case
where you have a secure channel.
I don't understand what the relevance of multi-factor is to invoices?
Yes, exactly. It's about paying who
there's no re-org handling at all.
If Electrum does end up doing all SPV work correctly, how is it different
to MultiBit? Just the deterministic wallet seeding?
On Fri, Nov 16, 2012 at 4:59 PM, Mike Hearn m...@plan99.net wrote:
Great to hear
I won't be able to make it this time. My feeling is IRC is a good place to
bounce ideas around when time and people happen to be available, but having
meetings there will inevitably lead to decision making that's better done
in a slower manner via email.
Comments:
BIP process: are we happy
Presumably these components will just get implemented a few times in
some carefully constructed library code, so I don't see an
implementation complexity argument here— except the fact that it isn't
what Matt has implemented so far.
Well, yes, that is basically the implementation complexity
Because I can potentially waste bandwidth of all nodes forever (well as long
as users are still scanning blocks with my transactions in them) with O(1)
work.
And this gets you what?
Users who have active wallets will have their bandwidth wasted for as
long as you keep up the attack. Once you
I've written a draft BIP describing the bloom filtering protocol
extension developed by myself and Matt.
https://en.bitcoin.it/wiki/BIP_0037
(yes I know there's some kind of process around getting allocated a
number - it seems overkill for this).
Please read it and let me know if there are any
Some questions:
* why limit the number of matching transactions to 255?
Copy/paste error in the does :(
* what does each hash and key in the output script mean exactly? what
about the output script in its entirety?
It's an informal way to say data elements. If you insert a key then it
What is the worst-case for an attacker interested in trying to get you
to saturate your upstream bandwidth or use lots of memory? Set a
bloom filter that matches everything, and then start requesting old
blocks in the chain?
It would be slightly worse than shipping a full block but not
No objections.
On Sun, Oct 21, 2012 at 7:05 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Any objections from other transaction-validating implementations?
I strongly support more precisely defining the transaction validity
rules by changing the reference implementation.
--
--
Gavin
+gary
Electrum also has a daemon for merchants.
Well, I suggest taking it up with Thomas directly. A thread here won't do much.
Considering the dislike of
Java that exist reflexively in much of the non-java community and the
greater ease of deployment and the integration of type-2 split key
I've been thinking about the requirements for a payment protocol
lately. It seems we have consensus that we need one of these. Pieter
has a gist on the topic here: https://gist.github.com/1237788
IMHO we'll want to move away from send X BTC to address Y and more
towards upload to me transactions
I think it's worth pondering the different things we may want in
future, even if that future is quite far out, just to ensure we have a
robust design that won't box us in later. Brainstorming feature ideas
now doesn't commit anyone to implementing them, but it may help
improve the final v1 design.
I'm pleased to announce the release of version 0.6 of bitcoinj, the leading
Java implementation of Bitcoin. You can download the source from Google
Code, or use the release-0.6 branch from git. Our Nexus repository will be
updated soon.
This release focuses on improved compliance with the
Sounds good— my only concern is that nodes will repeat their own
transactions but not the unconfirmed parents.
Nodes repeat wallet transactions and any previous transactions that
are not yet included in the chain (see
CWalletTx::RelayWalletTransaction). So I don't think it's an issue.
(ok,
Why Signing the input scripts as well would obviously make it
impossible to construct a transaction?
As it states in the source code, signatures cannot sign themselves. If
scriptSigs were included in the data that is being signed, the act of
inserting the newly calculated signature for one
501 - 600 of 642 matches
Mail list logo
