Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

> > But via Bluetooth it checks for 'ack' directly: We need a BIP70 conformance suite really. There are so many deviations from the spec out there already and it's brand new :( -- Download BIRT iHub F-Type - The Free Ente

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

> > At the moment I'm also modifying BitPay's memo field to contain 'ack', as > Andreas' wallet otherwise reports a failure if I transmit the original via > Bluetooth. :-) > Huh? -- Download BIRT iHub F-Type - The Free Ent

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

> > I read from your answer that even if we use ECDHE, we can't use it for > every situation. > Which situations do you mean? I think it can be used in every situation. It's the opposite way around - a fixed session key in the URI cannot be used in every situation.

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

> > This happened to one of the merchants at the Bitcoin 2013 conference in > San Jose. They sold some T-shirts and accepted zero-confirmation > transactions. The transactions depended on other unconfirmed transactions, > which never confirmed, so this merchant never got their money. > Beyond the

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

> > DHKE will not improve the situation. Either we use a simple method to > transfer a session key or a complex method. > You're right that just sending the session key is simpler. I originally suggested doing ECDHE to set up an encrypted channel for the following reasons: 1. URIs are put in Q

Re: [Bitcoin-development] bloom filtering, privacy

> > Adam seems to be making sense to me. Only querying a single node when an > address in my wallet matches the block filter seems to be pretty efficient. > No, I think it's less efficient (for the client). Quick sums: blocks with 1500 transactions in them are common today. But Bitcoin is growin

Re: [Bitcoin-development] bloom filtering, privacy

> > For downloading transactions unless you frequently receive > transactions you wont be fetching every block. Or are you assuming > bloom filters dialled up to the point of huge false positives? You > said otherwise. > Well, what I mean is, bitcoinj already gets criticised for having very low

Re: [Bitcoin-development] bloom filtering, privacy

Let's put the UTXO commitments/anti-fraud proofs to one side for a moment. I would like to see them happen one day, but they aren't critical to these protocols and are just proving to be a distraction. > Then they make fresh random connections to different nodes and request > download of the res

Re: [Bitcoin-development] bloom filtering, privacy

Hey Adam, > Mike had posted a detailed response on the topic on why its complex > and becomes bandwidth inefficient to improve it usefully. > To clarify, we *could* improve privacy and still preserve usefully high performance, it's just a lot of complicated programming work. You need to find out

Re: [Bitcoin-development] bloom filtering, privacy

> > It's a straight forward idea: there is a scriptpubkey bitmap per block > which is committed. Users can request the map, and be SPV confident > that they received a faithful one. If there are hits, they can request > the block and be confident there was no censoring. OK, I see now, thanks Greg

Re: [Bitcoin-development] bloom filtering, privacy

> > 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. This is the part where I get lost. How does this improve privacy? If I have to specify which addresses are mine in this block, to get the tx data, the node

Re: [Bitcoin-development] bloom filtering, privacy

> > This is talking about a committed bloom filter. Not a committed UTXO set. > I read the following comment to mean it requires the UTXO commitments. Otherwise I'm not sure how you prove absence of withholding with just current block structures+an extra filter included in the block: but with the

Re: [Bitcoin-development] bloom filtering, privacy

Ah, I see, I didn't catch that this scheme relies on UTXO commitments (presumably with Mark's PATRICIA tree system?). If you're doing a binary search over block contents then does that imply multiple protocol round trips per synced block? I'm still having trouble visualising how this works. Perhap

Re: [Bitcoin-development] Bitcoin ATM

Hi Fikret, This is the wrong mailing list for such questions. Most Bitcoin ATM's are commercial products anyway and don't accept contributors. If you find one that is different, it's better to contact them directly. On Fri, Feb 20, 2015 at 5:19 PM, Fikret AKIN wrote: > Hello, > > I want to im

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

> > He didn't said "a project for all possible language bindings", just > java bindings. Other languages' bindings would be separate projects. Yes/no/sorta. Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as dialects of Haskell, Lisp, Smalltalk and a bunch of more obscur

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > > history. Lots of miners have dropped out due to hardware obsolescence, > yet > > massive double spending hasn't happened. > > How many thousands of BTC must be stolen by miners before you'd agree > that it has, in fact, happened? > (https://bitcointalk.org/index.php?topic=321630.0) > Hmm. I

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > I see no fundamental difference in outcome from miner collusion in > scorched-fee (which isn't guaranteed to pay the "right" pool!) and miner > collusion in knowingly mining a doublespend transaction. > Well, they're the same thing. Replace-by-fee *is* miner collusion in knowingly mining a doub

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > So anyway, in my opinion, it is actually great that Bitcoin is still > relatively small: we have an opportunity to analyze and improve things. > But you seem to be hostile to people who do that (and who do not share > your opinion), which is kinda uncool. > To clarify once more, I'm all for pe

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > > So you're just arguing that a notary is different to a miner, without > spelling out exactly why. > I'm afraid I still don't understand why you think notaries would build long term businesses but miners wouldn't, in this model. I think you are saying because notaries have identity, brand awa

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > You can not consider the outcome resulting by replace-by-fee fraudulent, > as it could be the world as observed by some. > Fraudulent in what sense? If you mean the legal term, then you'd use the legal "beyond reasonable doubt" test. You mined a double spend that ~everyone thinks came 5 minut

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > 1. They won't be attacking Bitcoin, they will attack merchants who accept > payments with 0 confirmations. > Which is basically all of them other than exchanges. Any merchant that uses BitPay or Coinbase, for instance, or any physical shop. If you want to play word games and redefine "Bitcoin

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > You can prove a doublespend instantly by showing two conflicting > transactions both signed by thar party. This pair can be distributed as a > proof of malice globally in seconds via a push messaging mechanism. > There have been lots of e-cash schemes proposed in the academic literature that wo

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > But, let's say, 5 years from now, some faction of miners who own > soon-to-be-obsolete equipment will decide to boost their profits with a > replace-by-fee pool and a corresponding wallet. They can market it as "1 of > 10 hamburgers are free" if they have 10% of the total hashpower. > Yes, lik

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

> > Are you not counting collateralized multisignature notaries? Its an > extended version of the Greenaddress.it model. > It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party you can fix things, but then you're back to having th

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

I know you will ignore this as usual, but the entire replace-by-fee folly is based on your fundamental misunderstanding of miner incentives. Miners are *not* incentivised to earn the most money in the next block possible. They are incentivised to maximise their return on investment. Making Bitcoin

Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header

If you're interested in working on mining decentralisation, chipping away at getblocktemplate support would be a better path forward. It's possible to have decentralised pooled mining - I know it sounds like a contradiction but it's not. I wrote about some of the things that can be done in this bl

Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

We can certainly imagine many BIP70 extensions, but for things like auto-filling shipping addresses, is the wallet the best place to do it? My browser already knows how to fill out this data in credit card forms, it would make sense to reuse that for Bitcoin. It sounds like you want a kind of Star

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

> > verification using breadwallet on apple is much faster (<1s) than HTTPS > payment request on bitcoin wallet on android (apparently apple has a > significantly more optimized signature verification algorithm). Probably on Android it's being verified in Java instead of C++. Some Android APIs ar

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

BLE meets a different use case than regular Bluetooth. BLE is designed to allow always-on broadcast "beacons" which are conceptually similar to NFC tags, with very low power requirements. The tradeoff for this ultra-low power consumption and always on nature is the same as with NFC tags: you get ve

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

> > This sounds horrible. You could basically monitor anyone with a wallet in > a highly populated area and track them super easily by doing facial > recognition. > We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor? My watch lose

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

> > I'm imagining myself walking around broadcasting my photo and MAC > address while hucksters push payment requests to me for approval I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;) Bluetooth MAC addresses are random, they aren't useful identif

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

> > Even if a user could get the BIP70 URL in the URI, they would still need > internet to access the URL. > The way Bitcoin Wallet does it, the bitcoin URI includes a MAC address where you can download the request from. BIP70 does not depend on internet access or HTTP, plus, you don't have to sig

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

BIP70 requests can be sent over bluetooth as well, as can transactions. Bitcoin Wallet can already send money even when offline by doing this. It's transparent to the user. I mean original Bluetooth in this context - BLE has incredibly tight data constraints and isn't really meant for data transfer

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

> > For a BIP standard, I think we should skip "bitcoin:" URIs entirely and > publish BIP70 payment requests instead. > Agreed - it's not clear to me at all that this partial address scheme is actually secure. The assumption appears to be that the MITM must match the address prefix generated by th

Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware

> > TREZOR like devices with BIP70 support and third party cosigning services > are a solution I really like the sound of. I suppose though that adding > BIP70 request signature validation and adding certificate revocation > support starts to balloon the scope of what is supposed to be a very simp

Re: [Bitcoin-development] Proposal to address Bitcoin malware

> > In sending the first-signed transaction to another for second signature, > how does the first signer authenticate to the second without compromising > the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it

Re: [Bitcoin-development] Proposal to address Bitcoin malware

> > Do you have anything that is NOT some web application? > Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android

Re: [Bitcoin-development] Proposal to address Bitcoin malware

We're way ahead of you guys ;) On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak < martin.habovst...@gmail.com> wrote: > Good idea. I think this could be even better: > > instead of using third party, send partially signed TX from computer > to smartphone. In case, you are paranoid, make 3oo5 add

Re: [Bitcoin-development] Export format for xpub

We generally don't edit BIPs like that after they've been written except to add helpful links, examples etc and other things that don't add new functionality. For this you'd write a new BIP. It doesn't have to be hard. The process is: 1) Adapt the template BIP and fill it out with your motivation,

Re: [Bitcoin-development] Proposal to address Bitcoin malware

> > I see how BIP 70 verifies the payment request, however, is there any way > to verify that the transaction signed by the wallet matches the request > before it is sent to the blockchain (and how can this support out of band > verification)? > No. It cannot be done in the Bitcoin context. Your w

Re: [Bitcoin-development] Proposal to address Bitcoin malware

TREZOR does not support BIP70. I think they planned to work on it after multi-sig support, which is now done, so I'm hoping that it's next on their roadmap. The signing features of BIP70 have (fortunately!) been implemented by payment processors quite early, before we really have the client side f

Re: [Bitcoin-development] New BIP: protocol for multisignature payments

ot;here is how this thing I did > > works") and NOT proscriptive ("here's what I think will work, lets all > try > > to do it this way."). > > > > > > On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn wrote: > >>> > >>> I could

Re: [Bitcoin-development] New BIP: protocol for multisignature payments

> > I could look at implementing it someday, but now I'd like to receive > feedback from community. > IMO it's better to pair a protocol spec with an implementation. For one, it can show up issues in the design you didn't think of. For another, implementation is a lot more work than speccing out a

Re: [Bitcoin-development] New BIP: protocol for multisignature payments

Hi Martin, You're on the right lines. Your writeup is pretty similar to the high level overview given here though: https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation To make 2-of-3 dispute mediation works requires implementing a wallet that supports it, and the tools me

Re: [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?

> > "Alipay handled up to 2.85 million transactions per minute, and 54 percent > of its transactions are made via mobile device." > I know China is a very big place but even so - 47,500 transactions per second would be almost quintiple what Visa handles across the entire world. With only 300 milli

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

> > It is not "fear", it is field experience. > > JSON has proven to be a bug generator for the reasons already stated. > To back Jeff up on this point, today we see this story: http://www.theregister.co.uk/2015/01/27/trivial_hole_left_black_phones_open_to_plunder/ The maker of BlackPhone – a mo

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

ip the certs in the message and not depends on the transport. > > But a standard that just use JSON and HTTPS, even if less flexible that > BIP70, would make it easier and sufficient for today's use case. > > On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn wrote: > >> My poi

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

> > I'm frankly _horrified_ to learn that BitcoinJ ships its own root CA > certificates bundle. This means that, if a root CA gets breached and a > certificate gets revoked, all BitcoinJ-using software will be vulnerable > until BitcoinJ ships an update *and* the software in question pulls in the >

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

> > My point is not that there is a limitation in BIP70. My point is that you > put the burden of certificate verification on developer's shoulder when we > can just leverage built in HTTPS support of the platform. > Platforms that support HTTPS but not certificate handling are rare - I know HTML5

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

> > On the other hand, if you charge the developer (and not the plateform) to > check certificate validity, it means that you have to develop a different > codebase for all plateform you are targeting, because each plateform store > trusted root certificate in a different manner with different APIs

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

> > I hear that. But I don't see why mainstream wallets and wallets > designed for crypto research should not share a common core. > I think there was some misunderstanding. I was saying they *could and should* share common cores, so we are in agreement without realising it :) I also didn't mean t

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

> > I'm a bit confused. It's been a long time since I looked at protobuf (and > will have to dig into it soon), but I seem to recall it doesn't have any of > the determinism properties you guys just said. > It's not guaranteed no, which is why we store signed sub-messages as byte arrays instead o

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

The engineers at Google were well aware that ASN.1 existed. I can assure you of that, because I was one of them. The protobuf FAQ has a very polite take on the matter: https://developers.google.com/protocol-buffers/docs/faq This email thread gives more enlightenment: https://groups.google

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

Firstly, apologies to Nathan for not actually providing feedback on his protocol. I've put pondering it onto my mental todo list. The notion of a payment tree is interesting but complicated - I would need to think about it and maybe draw myself some diagrams before having useful feedback here. If y

Re: [Bitcoin-development] A look back and a look forward

> > This needn't be so, once an optional identity layer, modeled after the > Internet itself, is provided, as proposed in late August of last year on > this mailing list > I think the observation about Target vs Bitcoin exchanges is a sharp one, but I'm not sure how your proposal helps. You say it

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

The original design is documented at the bottom of here: https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party In this design, time locked transactions can be broadcast across the network and replaced by broadcasting a new transaction that

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

> > A limitation on most existing micropayment channel ideas is that payments > can only flow in one direction. > It's worth noting that the original protocol as designed by Satoshi did not have this limitation. It has evolved this way because of ad-hoc DoS fixes over time (btw I'm not saying they

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

Could you explain a bit further Sergio? I'm not sure I fully understand the proposal. How does adding inputs to a coinbase differ from just having pay-to-fee transactions in the block? -- Dive into the World of Parallel Pr

Re: [Bitcoin-development] Cartographer

> > Can you explain further where limitations and problems were hit? > Well, look at the feature list :) The biggest need from my POV is querying support. It's awkward to try and retrofit flexible key=value pair queries onto DNS, it just wasn't designed for that. With HTTP it's easy. This will be

[Bitcoin-development] Bitcoin XT

Hi there, I hope everyone who celebrates Christmas is having a relaxing and enjoyable break! :) I'd like to announce Bitcoin XT , a patch set on top of Bitcoin Core 0.10rc1 that focuses on enhancements to the peer to peer protocol. It is reproducibly built

[Bitcoin-development] Cartographer

Hi there! Lately we have been bumping up against the limitations of DNS as a protocol for learning about the p2p network. As a proposal for how to address this, I have written a new network crawler and seed: https://github.com/mikehearn/httpseed It implements a standard DNS seed with a minimal e

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

> > Finally, distributors of consumer wallets can use this research in > order to distribute their wallet with policies which may be less prone > to Tor-specific attacks. Or leave this out altogether if their > audience has different expectations for connecting to Bitcoin. > Sure. I guess there wi

Re: [Bitcoin-development] Serialised P2SH HD chains

I wrote a little Javascript program to print some minimal protobufs to base64. Result for a multisig output: Ik0SSRJHUiECpm1rIsOcaCf/CqL/YeqNXgcnQzb/+hfaawdi9u46xhEhAgoJfDU3M5mr++dfBG2gO5DiBiBVkVmLzjSLf

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

> > [As an aside I agree that there are lots of things to improve here, > but the fact that users can in theory be forced off of tor via DOS > attacks is not immediately concerning to me because its a conscious > choice users would make to abandon their privacy Bitcoin already has a large populat

Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

DKIM is hardly a PoW; signing is cheap and gets cheaper all the time. I used to work in the email business and big bulk mailers all spent far more CPU time on other aspects of their business, the overhead of DKIM is irrelevant. PoW didn't work in the anti spam world because it (amongst other probl

Re: [Bitcoin-development] Update on mobile 2-factor wallets

> > I am familiar with the Princeton threshold signature but I was under the > impression a single key needed to be generated on a single device then > split and distributed. > > Does this scheme work the same way? > No, it doesn't. Neither device ever sees as master private key. --

Re: [Bitcoin-development] Update on mobile 2-factor wallets

ite fragile. > > 2FA/2-of-2 does solve the common problem of single device compromise. > It also makes funds unspendable if -either- device's keys become lost. > > > > On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn wrote: > > Here is a summary of current developments in th

[Bitcoin-development] Update on mobile 2-factor wallets

Here is a summary of current developments in the space of decentralised 2-factor Bitcoin wallets. I figured some people here might find it interesting. There has been very nice progress in the last month or two. Decentralised 2FA wallets run on a desktop/laptop and have a (currently always Android

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

> > > Who benefits from not fixing bugs in Bitcoin? > > We can bring up politics if you want. No, please don't. That question was rhetorical, not an invitation for you to try and convince bystanders that anyone who disagrees with you is a shadowy Agent Of Centralisation or an idiot. You use that

Re: [Bitcoin-development] BIP62 and future script upgrades

This is another problem that only exists because of the desire to soft fork. If "script 2.0" is a hard fork upgrade, you no longer need weird hacks like scripts-which-are-not-scripts. --

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

Could you explain a little further why you think the current approach is statistically incorrect? There's no doubt that the existing estimates the system produces are garbage, but that's because it assumes players in the fee market are rational and they are not. Fwiw bitcoinj 0.12.1 applies the Ja

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

> > I'm not a cryptography expert, but why not just wrap the bluetooth > connection with SSL and not reimplement ECDH? Is this > hard to do with android/java? > Not at all, it should be very easy in Java because of how the SSL API is designed. I'd worry more about non-Java platforms. However, SSL

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

Hey Andy, Thanks for starting this discussion! One thing this brings up is the never-resolved issue of whether BIPs should document how we'd *like* things to work, or how things *actually do* work. BIP32 is an example of the former - it was new technology and the spec was finalised before any wal

Re: [Bitcoin-development] About watch-only addresses

> > This feature makes possible Bitcoin Core to read a balance of any > public address via RPC call or, after importing the balance, it became > available only via QT interface? Neither. A watching wallet still has to be synced with the chain in the same way as any other wallet, i.e. after adding

Re: [Bitcoin-development] BIP process

I don't care much what exact list software/service is used, but lists.sf.net hasn't changed in years and is basically dying. Trashing all @yahoo accounts because ancient mailman does a MITM attack on people's email is no good, it's not any better than a web proxy that breaks every SSL connection. F

Re: [Bitcoin-development] BIP process

> > Great idea. Jeff Garzik was looking for a better mailing list solution > than SourceForge, but assuming > there isn't a clearly better solution I think "we" should create a > strictly moderated bitcoin-bips@lists.sourceforge list. > Let's stay away from SF.net or any mailman-controlled lists i

Re: [Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue

I'm sure this suggestion will go down like a lead balloon, but Bitcoin Core is not the first project that's had issues with Linux distros silently modifying their software as they package it. In this case Luke has changed things to be closer to what users expect, which is good to see, but I expect

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

> > Yes, you're right. I didn't consider that case. But the problem is that > this is not automatic. Currently there is a clear division between > miners how will not take the kickback (irrrational) and miners who will > (rational). This seems to come up a lot. Your definition of rational is a sh

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

> > Opinion: if a soft work works, it should be preferred, if for no other > reason than once a hard-fork is planned, the discussion begins about > what else to throw in. To minimize the frequency of hard-forks, the > time for that is when the change being considered actually requires one. I'm n

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

> > That is easy to change; I'll submit a pull request. > That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. If there's going to be an intermediate release (6 months?) which lays the groundwork for

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

> > the block size being lower than the instant offered demand (there is > always a backlog) are both things which address the concern of this thread. > :) I'm skeptical such a situation can ever be stable. People have no incentive to create a transaction that will remain stuck in the backlog for

Re: [Bitcoin-development] bitcoinj 0.12

Hey Kristov, > I hate to reply to a release that includes a huge number of new features > with yet another feature request, so -- with apologies -- any plans for > bitcoinj to support stealth address sending and/or receiving? > Stealth addresses and SPV don't mix well, so no. I wrote up a descript

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

> > Anyway the stuff Mike is saying about being able to detect upgrades is > incorrect - detecting an upgrade is *easier* with a soft-fork, just look > at the block header nVersion numbers and warn the user if they increase > beyond what you know is valid. Bitcoin Core implements this IIRC, and > b

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

Alright. It seems there's no real disagreement about how the opcode behaves. Perhaps a time limit would be appropriate to stop people creating outputs locked for 100 years is bitcoin even likely to exist in 100 years? The entire history of computing is not even that old, seems hard to imagine

[Bitcoin-development] bitcoinj 0.12

I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. It is used by at least four Android wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets, for acad

Re: [Bitcoin-development] BIP72 amendment proposal

This adds only a few characters to a normal backwards-compatible QR code, and is not hard to implement. On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn wrote: > That way we leave up to implementers to experiment with different >> lengths and figure out what the optimum is > > > Ah, tha

Re: [Bitcoin-development] BIP72 amendment proposal

> > That way we leave up to implementers to experiment with different > lengths and figure out what the optimum is Ah, that's a good suggestion if we do go this way. -- Want excitement? Manually upgrade your production da

Re: [Bitcoin-development] BIP72 amendment proposal

Your example doesn't have an address in it at all, so isn't compatible with non-BIP70 wallets. Maybe for QRcodes specifically there are no longer any such wallets out there. For clickable links it can still be an issue. > I thought SHA1 has a bad reputation these days, and we don't save much > by

Re: [Bitcoin-development] BIP72 amendment proposal

A few thoughts on this: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute for

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

> > Not to mention encrypting basically non-sensitive inter-node traffic is > almost completely worthless in providing anonymity anyway... > Recall that P2P connections carry Bloom filters too, which are not public information. --

Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

> > Since when? This has been a recognized approach since people called it > "hashcash" ([1] - before cryptocurrencies were even invented). > I only know of one site that worked the way you propose: TicketMaster, a long time ago. They used it as a less harsh form of blocking for IPs that they stro

Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

> > Misbehaving addresses can have their connecting difficulty > scaled up, which should make it uneconomic to try to DoS the usage of > Tor exit nodes for connecting to Bitcoin. > You can't solve DoS by requiring all clients to do complicated work, all that means is that weak clients (like users

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

I would be very happy if we upgraded the P2P protocol with MAC keys and a simple home grown encryption layer, because: 1. It's practically guaranteed that 5-eyes intelligence agencies are either systematically deanonymising Bitcoin users already (linking transactions to real world identit

Re: [Bitcoin-development] Reconsidering github

If github were to be abandoned for anything, it'd make sense to move code review and bug tracking elsewhere. GitHub does a reasonably good job of hosting git repositories. It kind of sucks at code review and the issue tracker is rudimentary at best. These days you can do "log in with my github acco

Re: [Bitcoin-development] Outbound connections rotation

> > Connection rotation would be fine for improving a node's knoweldge > about available peers and making the network stronger against > partitioning. > It's also the first/next step towards decentralising the DNS seeds (for SPV clients), as it'd allow each node to explore the network and return b

Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

Putting the efficacy of coinjoin to one side: On Mon, Aug 11, 2014 at 1:38 PM, Tim Ruffing < tim.ruff...@mmci.uni-saarland.de> wrote: > Then the only remaining reason why it could be invalid is that the input > could have > been spent already otherwise. But in this case, only one honest client wi

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

> > I'd be OK with such an idea if bitcoind listens on a separate port for > connections from plugins, a port that cannot be used for normal P2P > traffic. This could also be a UNIX socket instead of a TCP port. Yes, can be done this way too. I was thinking about setups where you have services di

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

> > Yes, that is the one change I am still pondering: adding categories > (classes), rather than one single bit. > Sure, that makes more sense I think. As a motivating use case, Bitcoin Wallet for Android currently has a hard-coded block explorer (biteasy.com) which it uses to find UTXOs for a g

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

> > Something like `getutxos` or this proposal could be implemented as an > external application or script, instead of having to integrate > everything into bitcoind. > Right, although getutxos needs access to the UTXO set which bitcoind already has. An external plugin would have to recalculate it

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

I'd like to see a mechanism whereby a Bitcoin node can delegate processing of unknown messages to an external process, so a P2P node can be composed out of separated programs, but such a service would be indistinguishable at the network layer from one provided by Bitcoin Core itself, so a service b

<    1   2   3   4   5   6   7   8   9   >