>
> 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 ..
On Mon, Jan 13, 2014 at 2:37 PM, Roy Badami wrote:
> That does require trusting the third party not to later tamper with
> the payment request, though.
You have to trust the billboard owner too. If you're relying on a third
party to relay a payment instruction, that will always be an issue, hen
Cool!
On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman wrote:
> I spent 1BTC on TestNet to a stealth address...
> TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
>
... but can you redeem it?
> Code which generated this transaction is here:
> https://gist.github.com/
>
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.
>
I was thinking that people could upload a payment protocol file somewhere
once (like to their personal web page, or shared via dropbox or google
drive or some custom new pas
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman wrote:
> I think for displaying the payment in the UI after it's been made via
> PP, we have to fully support sending to a new standard address type anyway.
>
Why? Showing an address is meaningless, especially if the user didn't type
it in or see
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 bac
>
> 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
Bitcoin had an incredible year in 2013, and I very much enjoyed working
with and meeting you all.
I'm very much looking forward to some of the upgrades coming in 2014.
Though a lot happened in the general community, last year was kind of quiet
with respect to the core software. I'm hoping this yea
keys (or split shares
> of keys) may raise its own set of questions.
>
> For the download itself, I've heard the advocates of announcing
> availability on the blockchain leading to a BitTorrent magnet link, but I
> also understand objections to adding an entire BitTorrent stack into
>
> The site was actually moved onto a dedicated server temporarily and it
> melted down under the load. I wouldn't call that no progress.
>
Oh, it did? When was that? I must have missed this excitement :)
Any idea how much load it had?
Perhaps I wasn't clear on the point I was making Drak's thr
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
(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 and
>
> 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 transa
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 n
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. wrote:
> I was concerned about this issue so we sponsored Blue
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% vi
On Mon, Dec 16, 2013 at 11:13 AM, Drak 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 sending amount.
On Mon, Dec 16, 2013 at 12:31 PM, Pieter Wuille wrote:
> 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 bitcoinj. Only code revie
>
> 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 d
>
> 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
"super
> addresses", but to me, it seems that a lot of these privacy enhancing
> possibilities will be simple to implement once BIP32 is widely deployed.
>
>
> On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn wrote:
>
>> I wrote an article intended for a broad/non-de
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 discussions,
> That's an interesting question. The bitcoin.org domain is hiding
> behind a WhoisGuard anonymous registration. Why are we not allowed to
> know who this domain belongs to? Why are we being asked to trust some
> unidentified party?
It's done that way because it was originally registered by Sa
Issues that would need to be resolved:
1) Who pays for it? Most obvious answer: Foundation. However there's
currently a fairly clear line between the foundation website and the
bitcoin.org website. I personally am fine with the bitcoin foundation
funding the website, it's a lot closer to the bitco
On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd 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
comments - presuma
Please don't try and drag this thread off topic. What I said is factually
correct. If you want to (again) try and convince people things should work
differently, start another thread for that.
--
Sponsored by Intel(R) XDK
I think this US/other cultural issue is complicating things more than we
appreciate.
I am trying to imagine in my head how all this will work and what it will
look like with allow_fee, and I just can't see it. Merchants want customers
to pay the sticker price, deviance from that social norm is ext
Heh. People feel rises in sales tax elsewhere too. When VAT rises merchants
all raise their prices, they don't normally swallow it (or if they do, they
make a big fuss over how awesome they are).
The US system is a complete pain in the ass. You never know how much money
you actually need to pay fo
On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring wrote:
> 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 of people are psycho
On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen wrote:
>
> 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
> great way to enable
On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen wrote:
> Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care
> how many kilobytes their transactions are, and they will just be confused
> if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
> 9.9994 because t
On Tue, Dec 3, 2013 at 11:36 AM, Drak 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
reason we explo
On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen wrote:
> 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 if nobody ever used th
re to be done then I think 0.9 could go to
beta relatively soon, like early next year. There have been a lot of
improvements already and it'd be a shame to block them all further.
On Mon, Dec 2, 2013 at 3:37 PM, Jeff Garzik wrote:
> On Mon, Dec 2, 2013 at 9:33 AM, Mike Hearn wrote:
&g
s a stupid idea.
>
>
> On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn wrote:
> >
> > We need to get away from the notion of senders attaching fees anyway.
> This is the wrong
> > way around because it’s the recipient who cares about double spending
> risk, not the send
> 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 thems
> "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
>
> 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
> As long as the tx is not confirmed (by a broadcast), apps can offer to
> bump up the fee a little bit.
Unfortunately there are risks to that approach.
The most obvious one is that nodes could keep sending reject messages to get
wallets to attach ridiculously high fees. If half a wallets peers
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 n
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 :-)
>
>
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 part
perimental thing?
On Thu, Nov 21, 2013 at 2:55 PM, Addy Yeow wrote:
> Try https://bitcointalk.org/index.php?action=profile;u=19897?
>
>
>
>
> On Fri, Nov 22, 2013 at 12:48 AM, Mike Hearn wrote:
>
>> I added some additional logging to my node and ran it for a few days.
&g
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
2d1bbcc2bf64dfcb57a2f0180b2607a48a
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.
Hey Taylor,
It's great to see people thinking about payment protocol extensions. I'm
not totally convinced vCard support is the best idea relative to social
network integration - I can't recall the last time I saw someone use a
vCard. However, that should not hold you back from experimenting or
pr
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, TimeUnit.MILLISECONDS)
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
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
help
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 while
On Tue, Nov 5, 2013 at 6:43 PM, Ittay wrote:
> The attack can be easily hidden. And be sure that before today, today,
> and after today, very smart people are at their computer planning attacks
> on Bitcoin. Exploits must be published and fixed FAST.
>
I think it would be helpful if you actually
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 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/4/13 11:38 AM, Mike Hearn wrote:
> > The Merkle branch doesn't
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 wrote:
> No sense in compromising - you need a whole merkle path to prove the
> extra data is valid so you might as well make this a full 256
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd 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
process here -
>
> The suggested change is actually very simple (minutes of coding) and
> elegant and addresses precisely the identified problem.
>
Disagree. Unless I'm misunderstanding what they propose, their suggested
change would mean anyone could broadcast a newly discovered block at any
point and have a 50
On Mon, Nov 4, 2013 at 12:53 PM, Peter Todd 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 force.
>
They cou
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 a
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 wrote:
> Maybe this is a bit off-topic, but the *real* answer to the question
> "wh
> No, it wouldn't. You can log a user in using SSL and then redirect the
user back to an encrypted page
sorry, I meant unencrypted page of course
--
Android is increasing in popularity, but the open development platform th
On Sat, Nov 2, 2013 at 6:01 AM, wrote:
> In brief, the authentication work as follows:
>
>
>
> Server provides a token for the client to sign.
>
> client passes the signed message and the bitcoin address back to the
> server.
>
> server validates the message and honors the alias (optional) and bi
On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell wrote:
> If a node is using priority queued rate limiting for its relaying then
> it might "accept" a transaction from you, but have it fall out of its
> memory pool (due to higher priority txn arriving, or getting
> restarted, etc.) before it ever
On Wed, Oct 30, 2013 at 10:05 AM, Mark Friedenbach 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.
--
> 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
ndermining
that security model is problematic.
On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> Peter Todd wrote:
> >On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
> >> For block 0x11 ag
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 a
On Mon, Oct 28, 2013 at 1:14 PM, Adam Back 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 we're all sick of i
e-Jr wrote:
> 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 t
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 ac
Well, miners are all supposed to be more or less equivalent - modulo
differences in tx acceptance policies - so I'd hope that having out of bad
fee mechanisms yet still broadcasting the TX isn't that common. If it was
broadcasted, it should get mined in short order, otherwise things are going
wrong
On Thu, Oct 24, 2013 at 4:30 PM, Peter Todd 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 been paid.
This
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
Thanks! I'd love to see this library become usable behind a command line
flag or config setting. At some point we're going to want to switch to it.
I believe the main issue at the moment is the malleability issues? If so,
it would seem possible to use OpenSSL to parse the signature into
components
On Sat, Oct 5, 2013 at 4:31 AM, Gavin Andresen wrote:
> I'll try harder to be a fascist (it doesn't come naturally to me). HUGE
> thanks for taking the time to review the fee changes in detail.
>
Thanks, although I wasn't thinking specifically of you. The fee pull is
pretty well laid out. It just
On Fri, Oct 4, 2013 at 1:53 PM, Peter Todd 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 log.
>
> Why doe
> 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
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 eithe
alized names*. Probably a very small set :)
>
>
> On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn wrote:
>
>> Interesting observation, thanks.
>>
>> I'd think any competent implementation of such an identity scheme would
>> not involve end users directly handling ra
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 T
This kind of thing is better discussed in the dev forum of bitcointalk.org
On Sun, Sep 29, 2013 at 11:46 AM, Melvin Carvalho
wrote:
>
>
>
> On 29 September 2013 04:28, Neil Fincham wrote:
>
>> I subscribe to this list so I can keep up-to date with bitcoin
>> development, can we keep philosophy
BitPay invoice page for a normal browser.
>
>
>
> On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach
> 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
> >> provid
On Wed, Sep 25, 2013 at 1:33 PM, Andreas Schildbach
wrote:
> Why do you think that? Of course, I would skip the certificate, as its
> unnecessary if you see your partner in person.
>
OK, it might fit if you don't use any of the features the protocol provides
:) You can try it here:
https://bitco
> putting the payment request directly into the QR code.
>
>
> On 09/25/2013 11:27 AM, Mike Hearn wrote:
> > We could also say that if protocol part (https://) is missing, it's
> > implied automatically. So just:
> >
> > bitcoin:1abc?r=bob.com/r/aZgR
ote:
> On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn 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 q
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 ...
On Tue, Aug 20, 2013 at 12:05 PM, Mike Hearn wrote:
> I think the confidence
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?
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 wrote:
> > LevelDB is fast - very fast if you give it enough CPU time and disk
> seeks.
&g
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
You can prove ownership of a private key by signing a challenger-generated
nonce with the public part and giving the signature back to the challenger
- same as with any asymmetric crypto system.
As I already noted, the payment protocol is designed to solve that problem.
You could design a BIP that
Just a heads up,
Over a year ago Andreas and I prototyped bluetooth tx submission on Android
at a hackfest in Berlin, and it will be with support on-by-default for the
sending side soon. That means, anyone can enable the feature in the
settings page and start receiving payments via Bluetooth as lo
gest it
> requiring some non-trivial (for an end user) steps like getting a CA-signed
> certificate.
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Sep 7, 2013, at 11:44 PM, Mike Hearn wrote:
>
> > This is the sort of thing the payme
This is the sort of thing the payment protocol is for. The recipient would
vend a PaymentRequest containing identity details. The sender would submit
a Payment containing his/hers. The wallet then understands what to do.
On Fri, Sep 6, 2013 at 5:07 PM, Wendell wrote:
> Hi all,
>
> We're thinkin
It needs people to use either a dedicated app or a wallet with the right
features. I've gone back and forth on whether it's better to have wallets
become featureful things or to have lots of separate apps. There are pro's
and con's to each.
Fortunately bitcoinj makes bringing up a new GUI wallet a
On Thu, Sep 5, 2013 at 12:04 PM, Wendell wrote:
> Funny you should mention it! I just mocked this idea up last week, though
> I assumed a cruder system of "voting" to an address that corresponds to a
> feature -- literally, voting with your wallet (for your wallet, ad
> infinitum). I watched your
>
> Since this process would necessarily be somewhat manual and would of
> course be "undone" anytime the user changed his/her profile image, it is
> probably not a solution for everyone.
I guess these days most Facebook/G+/Twitter users are logged in from their
smartphone , so you'd implement it
Please do not post about this on bitcoin-development again. It's off topic
and you were already asked to stop.
On Wed, Sep 4, 2013 at 11:35 PM, Randolph D. wrote:
> Fwd:
> > V04 is out: Secure Instant Messenger
> > https://sourceforge.net/projects/goldbug/
>
>
>
Hey Wendell,
Interesting idea you have there!
On Wed, Sep 4, 2013 at 9:47 PM, Wendell 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 simpler to not think
That would be annoying for testing. Regtest mode allows you to create a new
block by just running "setgenerate true" (it switches itself off after
creating a block). If you had to set up a complicated set of separate
programs just to do regtest mode that'd be a step backwards, IMO.
On Thu, Aug 22
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 wrote:
> On
On Mon, Aug 19, 2013 at 2:13 AM, Peter Todd wrote:
> In any case given that SPV peers don't contribute back to the network
> they should obviously be heavily deprioritized and served only with
> whatever resources a node has spare.
Well, I'm glad we're making progress towards this kind of model
On Mon, Aug 19, 2013 at 5:09 AM, John Dillon
wrote:
> > 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
> > unconfirmed transactions ma
501 - 600 of 877 matches
Mail list logo
