I think we have a winner in reusable address. Yes an existing address can
be reused and will superficially appear to work, it just won't work well.
Calling them reusable addresses helps reinforce the idea in peoples mind
that the other kind shouldn't be reused.
On Thu, Jan 16, 2014 at 11:14 AM,
Yes correct, using hidden services just as a kind of more complicated, out
of process/sandboxable SSL.
would the overall transactions/second the Bitcoin network could handle go
down?
If all nodes talked to each other all the time over Tor, probably yes
because Bitcoin is quite sensitive to
Do any people who aren't computer programmers or physicists ever use the
term static?
I liked routing address.
On Wed, Jan 15, 2014 at 9:44 PM, Jeff Garzik jgar...@bitpay.com wrote:
static address seems like a reasonable attempt at describing intended
use/direction.
On Wed, Jan 15, 2014
May need to modify the network address format to include the ability to
differentiate IPv6 clearnet vs. Tor addresses
sipa already implemented some clever hack where the 80-bit Tor keys are
mapped to a subregion of reserved IPv6 space, giving magical IPv6 hidden
service addresses. So addr
Cool!
On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman jer...@taplink.co wrote:
I spent 1BTC on TestNet to a stealth address...
TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
... but can you redeem it?
Code which generated this transaction is here:
On further reflection, I'm not sure I understand this use case of the
payment protocol. Since a PaymentRequest currently contains the
Outputs that specify the addresses to send to, reusing a
PaymentRequest like this without using stealth addresses implies
address reuse.
Yes indeed ..
You can always just extend the payment protocol with the new fields as
well, vs making very long addresses. If this technique can be made to work
well, it would have applicability in both fixed textual address context,
and for a fixed/upload-once payment protocol file. That has the advantage
of
to a BitTorrent magnet link, but I
also understand objections to adding an entire BitTorrent stack into a
wallet.
On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote:
The site was actually moved onto a dedicated server temporarily and it
melted down under the load. I wouldn't call
Oh, it did? When was that? I must have missed this excitement :)
I would be very interested to learn more about this. It seems the steady
state load on the site is not very high:
https://github.com/bitcoin/bitcoin.org/pull/287
(Saivann ran Google Analytics on the site for a little while to
Given that hardly anyone checks the signatures, it's fair to say downloads
aren't protected by anything at the moment. SSL for downloads can only
raise the bar, never lower it, and if the NSA want to kick off the process
of revoking some of the big CA's then I'm game (assuming anyone detects it
of
I was reading there are some commands to access a peer's mempool state.
The purpose being to allow miners to recover faster after a reboot, I
think?
The mempool command allows nodes to request the contents of a peers
memory pool, yes.
It is currently used by SPV clients to find transactions
(nb: Gavin is on vacation at the moment, I post this now just to give food
for thought over the holidays).
I patched my bitcoind to use a modified version of Gavin's fee estimation
framework. Here is what it's currently estimating. This shows number of
samples taken for fee-paying transactions
For a long time the only block explorer for testnet has been the original
blockexplorer.com, which is unfortunately often broken / behind / slow and
not really maintained any more.
There is now a new one, here:
https://www.biteasy.com/testnet/blocks
There's also a REST/JSON API for it.
Please
Thanks Warren! That's great. It's also a prerequisite for chain pruning, so
it's not only about decentralisation but also scalability.
Looking forward to reviewing and merging that.
On Tue, Dec 24, 2013 at 6:11 PM, Warren Togami Jr. wtog...@gmail.comwrote:
I was concerned about this issue so
It is irrelevant.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100%
On Mon, Dec 16, 2013 at 12:31 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
Will that also mean no longer reusing (change) addresses?
Jim seems to be planning some parallel development to what I'm doing, but
HD wallets and stopping address re-use is the current feature I'm working
on for
On Mon, Dec 16, 2013 at 11:13 AM, Drak d...@zikula.org wrote:
It just occurs to me this kind of sad story could be averted if wallets
implemented a confirmation box if the fee amount seems crazy - for example,
if it's 10x what the default fee should be, or if it's greater than x% of
the
Why would there be an iteration count? The payer would handle that,
wouldn't they?
I'm thinking about a use case I hope will become common next year -
pastebin style hosting sites for payment requests. Like, if I as a regular
end user wish to use the payment protocol, I could just upload a
Or alternatively, the user-signed payment request without iteration
count is enclosed within a payr.com-signed envelope that contains the
iteration count.
But how does that show up in the user interface? I don't know how you would
explain what the signature means or implies, or what you do
I wrote an article intended for a broad/non-developer audience on a few
Bitcoin privacy topics:
- P2P connection encryption
- Address re-use/payment protocol
- CoinJoin and merge avoidance
I don't think there's anything much new here for people who were involved
with the BIP70 design
is widely deployed.
On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn m...@plan99.net wrote:
I wrote an article intended for a broad/non-developer audience on a few
Bitcoin privacy topics:
- P2P connection encryption
- Address re-use/payment protocol
- CoinJoin and merge avoidance
I don't think
On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd p...@petertodd.org wrote:
replace-by-fee is no less speculative than your original proposals;
you're also trying to convince people that things should work
differently re: fees
The original proposal I started this thread with hasn't even received
On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen gavinandre...@gmail.comwrote:
optional uint64 allowfeetag number=1000
Let's just use a normal/low tag number. The extensions mechanism is great
for people who want to extend the protocol outside the core development
process. It'd be weird
On Tue, Dec 3, 2013 at 11:36 AM, Drak d...@zikula.org wrote:
I dont like the idea of putting the min fee in the hands of the receiver.
Seems like that will work against the best interests of senders in the long
run.
Senders have no interest in ever attaching any kind of fee, which is one
On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen gavinandre...@gmail.comwrote:
If users want to pay with a huge transaction then it seems to me the user
should cover that cost. Allowing users to pay merchants with 100K
transactions full of dust and expecting them to eat the cost seems like a
On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring taylor.gerr...@gmail.comwrote:
Why should there be two classes of transactions? Where does paying a local
business at a farmer’s stand lie in that realm? Transactions should work
the same regardless of who is on the receiving end.
Lots and lots
Lately I was pondering how to make floating fees and SPV wallets work well
together.
I propose the following plan:
1) 0.9 ships with something dead simple, like a command to query what a
node estimates and then clients just take the average, or cross-check a
centralised estimate against the P2P
Both can be combined into adapting the current generic messages (This
payment should become spendable shortly for incoming and This payment
has not been transmitted yet for outgoing transactions).
What would the new messages say?
We need to get away from the notion of senders attaching fees
This payment did not become spendable since xxx minutes. Check with the
sender if s/he paid the Bitcoin network fee. Check if your internet
connection is working properly. (incoming)
That seems reasonable.
The other message should be implementable today, I think? If numBroadcastPeers
0
Bitcoin is and always will be limited in capacity - transactions may not
confirm in a reasonable about of time because of high-demand and/or DoS
attacks.
I agree in the general case, but I was talking about the mobile wallet case
specifically (i.e. people who are sending money between
Hey Christian,
Could you sort the snapshots by date? At the moment they're kind of in a
random order.
Sometimes I wish we had real-time stats too but this is a great start.
On Mon, Nov 25, 2013 at 8:27 PM, Christian Decker
decker.christ...@gmail.com wrote:
Thanks Mike for the Tip :-)
I
This is great, thanks for doing it. Tip sent your way.
Graphs of how propagation data change over time would also be helpful (as
well as raw data so we can calculate overhead per kilobyte and so on). I
know there are only two days worth of data, but for future, it'd be good.
I think the next
thing?
On Thu, Nov 21, 2013 at 2:55 PM, Addy Yeow ayeo...@gmail.com wrote:
Try https://bitcointalk.org/index.php?action=profile;u=19897?
On Fri, Nov 22, 2013 at 12:48 AM, Mike Hearn m...@plan99.net wrote:
I added some additional logging to my node and ran it for a few days.
There's a pull
I added some additional logging to my node and ran it for a few days.
There's a pull req open for my extra logging, it is quite trivial. Here's
what it looks like:
2013-11-21 13:41:04 AcceptToMemoryPool:
5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
I don't use testnet much anymore, partly because it sometimes kind of
breaks like this. It's a public resource and people sometimes abuse it.
You can create your own local network with -regtest and that lets you mint
new blocks instantly. It's a much simpler way to do testing and app
development.
I took a brief look at the code - it's looking very reasonable. You can
replace any construct like
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
which is quite verbose, just with
Uninterruptibles.sleepUninterruptably(1000,
I think trying to help miners figure out the propagation/fees tradeoff at
the moment is a non-starter until we understand it better ourselves. A
server that tracks and records block propagation times, how many fees per
passed up per block, orphan stats per size bucket etc would be tremendously
Once the ASIC race calms down because everyone has one, has more or less
optimal power supplies, process improvements aren't easily reachable
anymore etc then I'd expect people to dissipate from the large pools
because eliminating their fees will become the next lowest hanging fruit to
squeeze out
Very cool, thanks Matt.
I was actually thinking this morning, maybe we should require all nodes to
go through the inv/getdata dance. Otherwise it's possible to improve your
chances at racing a block by mining a block, waiting to see a block inv
from another node, then blasting out your block
W.R.T. this paper and the oft-discussed miner backbone,
http://arxiv.org/pdf/1311.0243v1.pdf
I'm wondering about an alternative protocol change that perhaps has less
subtle implications than their suggested change. Rather than address the
problem by assuming the network is full of sybil nodes
On Mon, Nov 4, 2013 at 12:53 PM, Peter Todd p...@petertodd.org wrote:
I proposed this as a means of giving a mechanism for wallets to get
non-sybilled peers as well.
Ah yes, good point.
Doing so encourages pools to only bother connecting to other pools,
which is a strong centralizing
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd p...@petertodd.org wrote:
The attacker now only needs to connect to every identified miner
with especially fast nodes. With judicious use of DoS attacks and low
latency .
So you're back to a complicated sybil attack. I don't follow your thought
I like the UUID-as-path idea. That resolves the problem of how to share the
alt-chain merkle tree quite nicely.
On Mon, Nov 4, 2013 at 7:16 PM, Peter Todd p...@petertodd.org wrote:
No sense in compromising - you need a whole merkle path to prove the
extra data is valid so you might as well
Yes, sure. I was talking about the case of transiently relayed data, like
IP addresses.
On Mon, Nov 4, 2013 at 8:53 PM, Mark Friedenbach m...@monetize.io wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
The Merkle branch doesn't get stored
Guys, identity systems for the web are off-topic for this list. Other than
the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any
relevance to it.
On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo hannu.kotip...@iki.fiwrote:
Maybe this is a bit off-topic, but the *real* answer
But if you are getting soft-forked recent versions of the reference
implementation WILL alert you; see this code in main.cpp:
Perhaps I'm confused about how we're using the term soft fork. My
understanding is that this is where a new upgrade is designed to look valid
to old nodes, and if you
On Wed, Oct 30, 2013 at 10:05 AM, Mark Friedenbach m...@monetize.io wrote:
If I understand the code correctly, it's not about rejecting blocks.
I was referring to the fork alerts that Matt did. They also alert you if
there's a missed upgrade.
For tx reject, should there be a code for unknown version? That is,
tx.nVersion bestKnownVersion == reject? In that case 0x40 would become
non-standard transaction type. I think unknown transaction type is a
bit vague. Or do we want new tx messages to always be backwards compatible?
0x42 and
that security model is problematic.
On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd p...@petertodd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter Todd p...@petertodd.org wrote:
On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
For block 0x11 again shall
On Mon, Oct 28, 2013 at 1:14 PM, Adam Back a...@cypherspace.org wrote:
Maybe I voice this opinion a bit late in the cycle, but
A bit late is one way to put it. All these topics and more were discussed
to death a year ago when the payment protocol was first being designed.
Bluntly, I think
Yeah, something like HTTP would work well.
I'm really looking forward to this. Currently bitcoinj gets a small but
steady stream of bug reports of the form my transaction did not
propagate. It's flaky because the library picks one peer to send the
transaction to, and then watches it propagate
:
On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:
Currently bitcoinj gets a small but steady stream of bug reports of the
form
my transaction did not propagate. It's flaky because the library picks
one
peer to send the transaction to, and then watches it propagate across
On Thu, Oct 24, 2013 at 4:30 PM, Peter Todd p...@petertodd.org wrote:
Quick thought on how to make blockchain-based fee estimates work better
in the context of out-of-band mining contracts: have miners advertise in
their coinbase's what fees were actually paid, as opposed to appear to
have
I was hoping to see something interesting and useful, but all I saw was
absurd ranting. Example quote:
It is not known where bitcoin contributors are based. Gavin Andersson, a
major contributor, is a well-known South African
anarchist/crypto-libertarian. Most contributors hide their identities.
I
Git makes it easy to fork peoples work off and create long series of
commits that achieve some useful goal. That's great for many things.
Unfortunately, code review is not one of those things.
I'd like to make a small request - when submitting large, complex pieces of
work for review, please
There is more to a git branch than just the overall difference. Every
single
log message and diff is individually valuable.
When the log messages don't accurately describe the contents of the diff,
it's just misinformation and noise. Everyone starts out by wanting a neat
collection of easy
On Fri, Oct 4, 2013 at 1:53 PM, Peter Todd p...@petertodd.org wrote:
When I'm reviewing multiple commit pull-requests and want to see every
change made, I always either click on the Files Changed tab on github,
which collapses every commit into a single diff, or do the equivalent
with git
Interesting observation, thanks.
I'd think any competent implementation of such an identity scheme would not
involve end users directly handling randomized nonsense words, however. I
always imagined a sacrifice as being a file that you make with a GUI tool
and load into a browser extension.
On
small set :)
On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn m...@plan99.net wrote:
Interesting observation, thanks.
I'd think any competent implementation of such an identity scheme would
not involve end users directly handling randomized nonsense words, however.
I always imagined a sacrifice
...@gmail.comwrote:
On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net wrote:
BTW, on the make qrcodes more scannable front -- is it too late to
change BIP 72 so the new param is just r instead of request? Every byte
helps when it comes to qrcodes ...
Not too late, assuming
for a normal browser.
On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach
andr...@schildbach.de wrote:
On 09/25/2013 01:45 PM, Mike Hearn wrote:
OK, it might fit if you don't use any of the features the protocol
provides :)
Now you're dver-dramaticing (-:
I'm just skipping one feature
LevelDB is fast - very fast if you give it enough CPU time and disk seeks.
But it's not the last word in performance.
HyperLevelDB is a forked LevelDB with some changes, mostly, finer grained
locking and changes to how compaction works:
http://hyperdex.org/performance/leveldb/
However, it comes
of the libdb4.8++-dev
dependency that makes bitcoind harder to compile on debian and ubuntu.
Unless, of course, there's a reason I am missing...
On 9/17/13, Mike Hearn m...@plan99.net wrote:
LevelDB is fast - very fast if you give it enough CPU time and disk
seeks.
But it's not the last word
The payment protocol doesn't *require* signed certificates, it just gives
the option of using them.
However if you don't have some kind of cryptographic proof of identity,
what stops me putting your name and face into my payment requests and
claiming to be you?
Hey Wendell,
Interesting idea you have there!
On Wed, Sep 4, 2013 at 9:47 PM, Wendell w...@grabhive.com wrote:
Obviously there are a couple of brain-dead approaches: We could track what
users do in the app, and send the business a bill (with blockchain proof,
of course).
It might be
I think the confidence of the tx is not really the users concern anyway.
They wrote it so they know it's valid. If the merchant disagrees for some
reason then the user can find out, out of band when the goods/services are
not delivered.
On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen
On Mon, Aug 19, 2013 at 5:09 AM, John Dillon
john.dillon...@googlemail.comwrote:
Here's another question for you Mike: So does bitcoinj have any
protections against peers flooding you with useless garbage? It'd be
easy to rack up a user's data bill for instance by just creating junk
The original Bloom filtering spec did not make this feature optional for
the same reason gzip isn't an optional part of the PNG specification. I see
no reason to revisit that. It's definitely not the case that making every
possible feature optional is smart design, often it's the opposite.
If in
I filed a bug in the bitcoinj tracker for this a few days ago referencing
rfc 6967, but that RFC is very complicated and I'm not sure it's really
necessary to go that far. H(sighash||key) is easy to implement and I feel I
understand it better.
In our case it wouldn't have helped anyway - if
Cool. Maybe it's time for another development update on the foundation blog?
On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen gavinandre...@gmail.comwrote:
Mike asked what non-0.9 code I'm working on; the three things on the top
of my list are:
1) Smarter fee handling on the client side,
be the
whitepapers. At the moment we still have plenty of headroom in block sizes,
even post April. It can probably be safely delayed for a while.
On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn m...@plan99.net wrote:
Cool. Maybe it's time for another development update on the foundation
blog?
On Fri
that.
On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn m...@plan99.net wrote:
The only other thing I'd like to see there is the start of a new anti-DoS
framework. I think once the outline is in place other people will be able
to fill it in appropriately. But the current framework has to be left
That change was made in response to user complaints. Heck we get complaints
about battery life and bandwidth impact even with Bloom filtering. We can't
just randomly start using peoples bandwidth for relaying blocks, especially
as I guess most SPV nodes are behind NAT.
If Gavin is right and the
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd p...@petertodd.org wrote:
UPNP seems to work well for the reference client. What's the situation
there on Android?
Not sure - it could be investigated. I think UPNP is an entirely
userspace-implementable protocol, so in theory it could be done by a
Sounds awesome!
Pieter told me at lunch that headers first cut sync time to 45 minutes for
him, which is another amazing improvement from the master of optimisations.
Pieter, Matt and I also agreed that for maximum impact we should really try
to ship payment protocol support in at least two
On Thu, Aug 15, 2013 at 10:22 AM, slush sl...@centrum.cz wrote:
We're planning to support payment protocol in Trezor as well, if it
counts. I think it's a missing piece in absolute security of hardware
wallets.
Yup, that's always been the plan :-)
Any idea how much work it is, and would it
Our plan is to add support for that into v1 firmware, but it also depends
on readiness of surrounding infrastructure; mainly if there'll be support
for payment protocol in multibit in the time of v1 release (I suppose that
the Multibit will be the first wallet compatible with Trezor AND
Hello,
I'm pleased to announce version 0.10 of bitcoinj, a Java library for
writing Bitcoin applications. BitcoinJ has been used to create everything
from end-user wallet apps to network crawlers to SatoshiDice.
To learn how to obtain bitcoinj 0.10, please see the following page:
This is just me making notes for myself, I'm not seriously suggesting this
be implemented any time soon.
Mozilla Persona is an infrastructure for web based single sign on. It works
by having email providers sign temporary certificates for their users,
whose browsers then sign server-provided
to native apps (they get their own windows, run offline,
etc).
But these aren't standard APIs. They're all Chrome extensions. I doubt
HTML5 will support USB access anytime soon, for instance, but packaged apps
do.
On Fri, Aug 9, 2013 at 2:10 PM, Mike Hearn m...@plan99.net wrote:
Code that runs
it necessary
to check with Alice first. That's more of an interface issue though. We
can add a warning to check with the recipient that they still have access
to wallet 3cQ398x, etc. But I just know someone is going to lose money
anyway...
-Alan
On 06/20/2013 03:32 AM, Mike Hearn
I'd have much to contribute (besides requesting a feature
I know isn't there). I was planning to wait until it was complete before
fully grokking and implementing it in Armory.
On 08/09/2013 03:58 PM, Mike Hearn wrote:
Payment protocol is locked down for v1 already. But did you read
I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ? The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.
bitcoinj separates the concept of committing a
They have poor space/bandwidth usage properties, which is one reason
why Bitcoin doesn't use them today, but as far as I know the same is
so for all post-QC schemes.
I believe post-QC schemes based on Regev's LWE assumption are getting
competitive with more traditional schemes. A paper from
Support for a TPM is a rather tricky thing.
By itself the TPM is independent of any CPU. However, it's also not very
useful (though for Pond's use case, it works).
The TPM gets much more useful when it's integrated with features on the
motherboard, BIOS, CPU, northbridge, IOMMU etc. Then you
Sorry, I just noticed that this thread was CCd to the announce list not the
development list (why is it open access?)
It's offtopic anyway. Let's continue this discussion in private if anyone
wants to.
On Wed, Jul 31, 2013 at 5:53 PM, Mike Hearn m...@plan99.net wrote:
The reason why TPM
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote:
As a testament to the seriousness with which Pond takes forward
security, it can use the NVRAM in a TPM chip to reliably destroy keys for
data that an SSD device might have otherwise made un
Various ideas are possible:
* Use the Tor SOCKS proxy in such a way that it creates a guaranteed
independent circuit to a different exit node each time you connect. This
gets you back to the slightly stronger clearnet heuristic of if I saw a
bunch of peers announce my tx, then it's probably
TPMs have come as standard with nearly all computers (except Macs, doh) for
a long time. They certainly don't cost $100. More like a few dollars at
most. That's why they're so slow.
On Tue, Jul 30, 2013 at 10:43 PM, grarpamp grarp...@gmail.com wrote:
On Tue, Jul 30, 2013 at 8:12 AM, Mike Hearn
As an FYI, I've sent Wendell and co some example code for how to use CPPJVM
to use bitcoinj from native code. A rather rough Hello World app looks like
this:
https://github.com/mikehearn/cppjvm/blob/master/mytest/bcj-hello-world.cpp
So, fairly C++ like.
Further discussion of this should take
This isn't usable for SPV wallets unless it has a birthday in it. Otherwise
you either need to scan the entire chain (slow) or find a fully indexed
copy of the block chain (expensive, more centralised). Just add a UNIX time
as an extra 4 bytes, or if you want to save a few characters then use a
to
start only storing relevant outputs in the wallet and doing other things to
try and save memory. Some people managed to get themselves wallets that
don't actually fit in ram :(
On 21 Jul 2013 17:55, Pieter Wuille pieter.wui...@gmail.com wrote:
On Tue, Jul 16, 2013 at 12:59:56PM +0200, Mike Hearn
The 90 minutes is not - the blockchain has grown quite a lot since last
year, and as for the 3.5 speed, I havn't tested it since Pieter's
ultraprune - libcoin also has something similar to ultraprune, done
directly in the sqlite database backend, but I should run a head to head
again - could
SPV clients behaving normally are highly abusive: they use up maximum
node resources with minimum cost to themselves.
This must be a new use of the word abuse I haven't come across before :)
At any rate, some of these assumptions are incorrect. Botnets of
compromised web servers are quite
:
Hello everyone,
In the previous thread, I expressed interest in seeing an SPV bitcoind,
further stating that I would fund such work. Mike Hearn followed up with
some of Satoshi's old code for this, which is now quite broken. The offer
and interest on my side still stand, as more diversity
On Wed, Jul 17, 2013 at 2:37 PM, Tamas Blummer ta...@bitsofproof.comwrote:
A majority coalition of miner (pool operator) might even decide to change
block reward
rules if the rest of the network only verifies POW.
Which is why it's still vital that any important node in the economy uses
full
as the screen is on and the app
in the foreground (= resumed state).
On 07/17/2013 02:29 PM, Mike Hearn wrote:
Partial UTXO sets is a neat idea. Unfortunately my intuition is that
many SPV wallets only remain open for 1 minute at a time because the
user wants to see they received money
Clear. Your right. C++ would give us more flexibility (other platforms)
and also android compatibility (through NDK).
I'm a bit confused I'm afraid. bitcoinj already runs SPV wallets on Android
on top of Dalvik. In fact that's what it's designed for. The NDK is not
necessary to work with
Let's re-add the list as this is a topic of general interest.
On Tue, Jul 16, 2013 at 11:36 AM, Jonas Schnelli jonas.schne...@include7.ch
wrote:
What do you think about extending the BitcoinKit.framework (based on
bitcoind) so that the kit could handle the very basic SPV concept
(getHeaders
interest in seeing an SPV bitcoind,
further stating that I would fund such work. Mike Hearn followed up with
some of Satoshi's old code for this, which is now quite broken. The offer
and interest on my side still stand, as more diversity in SPV options seems
like the right way to go.
Time
401 - 500 of 642 matches
Mail list logo
