Re: [Bitcoin-development] we can all relax now
I might try building this sometime soon. I think it may also serve an educational purpose when trying to understand the whole network's behaviour. What level of accuracy are we looking for though? Obviously we need to fully emulate the steps of the network protocol, and we need to be able to specify time taken for transmission/processing for each node. Do we care about the actual contents of the messages (to be able to simulate double spend attempts, invalid transactions and blocks, SPV node communication), and their validation (actual signatures and proof of work)? I imagine the latter is pretty useless, beyond specifying that the signature/proof of work is valid/invalid. If we could build up a set of experiments we'd like to run on it, it would help clarify what's needed. Off the top of my head: - Peter Todd's miner strategy of sending blocks to only 51% of the hashpower. - Various network split conditions, and how aware of the split nodes would be (and the effect of client variability). - Testing the feasability of network race double spends, or Finney attacks. - Various network partition scenarios. - Tricking SPV nodes. On Nov 6, 2013 6:37 AM, Jeff Garzik jgar...@bitpay.com wrote: I will contribute 1 BTC to this bounty, under same terms and expiration. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Network Simulator
Beat me to it. My own implementation is here: https://github.com/christophebiocca/bitcoin-network-simulator Same basic principles, but I've been following the protocol message structure as much as possible/Theoretical support for transaction propagation (I really want to see zero-conf stuff, and whether it works). Running a network of 1000 full nodes (with 100 miners) for a week of simulated time (with a normal hashrate) and empty blocks (except for the coinbase transaction) takes about 30-60 seconds. Uses nodejs, with the ultimate goal of having a network/chain visualization running in the browser (with the actual simulation running on a WebWorker to keep things responsive). On Sun, Nov 17, 2013 at 11:43 AM, Rafael Brune m...@rbrune.de wrote: Over the last days I spent some time working on a simple Bitcoin network simulator. It is a stochastic event-based continuous-time simulation of Bitcoin miners exchanging messages and building block chains. It simulates latency, bandwidth and also verification speed but it currently does not simulate propagation/inclusion of transactions and instead uses random block sizes. The simulator includes two examples, one for a 51% attack and the other is an implementation of selfish mining (pretty much 1:1 as described in the paper). With the random parameters I picked it seems like it pays off to mine selfish with =30% of the hashing power - but take this with a huge grain of salt as this is with a very small network and randomly chosen parameters. And of course it is not a perfect replica of the real world network. Since this is based on my understanding of the Bitcoin network and protocol it would be great if others would take a look and help improve it. The project can be found on my github: https://github.com/rbrune/btcsim Regards, Rafael Brune -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees
To clarify, there are proposals to make miners recognize this situation and account for it, only eligius is running it at the moment IIRC: http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-large-miners-running-child-pays-for-parent-patch Right now if you were to try it likely wouldn't result in inclusion. But this is on the radar, and I suspect it'll eventually get merged into mainline. On Thu, Jan 16, 2014 at 9:06 PM, Dâniel Fraga frag...@gmail.com wrote: This is good news! Thank you very much Ben for the answer. On Thu, 16 Jan 2014 17:52:39 -0800 Ben Davenport bendavenp...@gmail.com wrote: You can create a transaction which spends the output to yourself, attaching a fee to that transaction. In order for miners to grab the transaction fee on that transaction, they would have to also mine the original transaction. Likely, you'd have to do this by hand, but software could be written to simplify doing it. No protocol changes needed. Ben On Thu, Jan 16, 2014 at 5:39 PM, Dâniel Fraga frag...@gmail.com wrote: Someone sent me a very small donation (0.00121 BTC) without paying fees. I don't know who sent it and I know this type of transaction are usually rejected by miners. Take a look at it below: https://imageshack.com/i/ngv5g8j Even with the a low probability of confirmation, I was hoping that after a few days it could be included in a block, but Blockchain.info simply removed it (I know the sender sent from a Blockchain.info wallet, because he added a note): https://blockchain.info/pt/tx/3cde47ee3979a46b36bd61bdb0caf9c11dea58ac99f17fb17b95728766de70e0 As you can see now it shows as Transaction not found. My suggestion is: it would be nice if the receiver could have a chance to pay the fee when the sender didn't pay any fee. For example, I could pay a fee of 0.0001 BTC and receive 0.00121 BTC. In the end I'd have 0.00111 BTC. Better than nothing. Would it be technically possible to do that or it would be too much trouble to change the protocol to allow the receiver to pay an optional fee? Ps: I'm not a programmer, but if the receiver could optionally attach some fee to the transaction, even if he/she didn't sent the transaction, this could be solved. Bitcoin-qt could even warn the receiver he received a transaction without fee and if he wants faster confirmation he could pay a fee. Ps2: if this is a silly suggestion, just ignore it. I tried on Bitcointalk, but nobody answered. -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)
Like any other mechanism that puts extra data in the blockchain, the sender pays the fees. This mechanism is to improve privacy for static addresses (donation links on websites and so on). I personally don't think it will be used nearly as much as BIP0032 or the payment protocol (both of which don't need on-blockchain data), precisely because it increases the fees required to send funds, but this doesn't externalize costs anymore than any other use of the blockchain does. People who don't care about privacy and want smallest cost and maximum convenience already use SPV nodes. Their resource usage will not be affected in the least. On Sat, Jan 18, 2014 at 12:44 PM, Troy Benjegerdes ho...@hozed.org wrote: On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote: On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman jer...@taplink.co wrote: Choosing how many bits to put in the prefix may be difficult, particularly if transaction load changes dramatically over time. 0 or 1 bits may be just fine for a single user running their own node, whereas a central service might want 4 or 5 bits to keep their computation costs scalable. Ignoring prefixes the cost for each reusable address is only a small percentage of the full node cost (rational: each transaction has one or more ECDSA signatures, and the derivation is no more expensive), so I would only expect computation to be an issue for large centralized services. (non-full nodes suffer more from just the bandwidth impact). I have not seen anyone address my high-level question to (somewhat) complicated mechanisms to keep coin flows private. Who pays for it? From what I see it's going to double the amount of data needed per address, further centralizing 'full' nodes. I'm fine if the NSA is paying for privacy (I actually trust them more than banks and advertisers), but let's just be honest, okay? If socializing the cost of privacy is Bitcoin's goal, and giving the benefits to a few that understand it and/or have the resources to determine privacy providers that won't scam them, then say so, so I can get on with launching a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses addresses, and has miners and pools that charge more for addresses they have never seen before. I bet it will be more distributed and have about half the average transaction cost of Bitcoin, because most people *just don't care* about privacy if they get cheap and/or free services. -- Troy, transparency advocate who is quite transparent that if you buy me farmland, I'll shut up about transparency, because I'll be too busy growing food and giving part of it away. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039: Final call
I remember the wordlist choice getting bikeshedded to death a month ago. I would just include the wordlist as part of the standard (as a recommendation) so that fully compliant implementations can correct a user's typos regardless of the original generator. Those who don't like it will have to deal with the compatibility concerns themselves, or get an alternate wordlist approved as a BIP. Odds are no one will go that route. On Mon, Jan 20, 2014 at 5:35 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote: On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz wrote: Hi all, during recent months we've reconsidered all comments which we received from the community about our BIP39 proposal and we tried to meet all requirements for such standard. Specifically the proposal now doesn't require any specific wordlist, so every client can use its very own list of preferred words. Generated mnemonic can be then applied to any other BIP39-compatible client. Please follow current draft at https://github.com/trezor/bips/blob/master/bip-0039.mediawiki. So, because the [mnemonic]-[bip32 root] is just hashing, you've effectively made your mnemonic sentence into a brainwallet? Since every mnemonic sentence can now lead to a bip32 root, and only the client that created the mnemonic can verify the mnemonic passes its checksum (assuming all clients use different wordlists, the only client that can help you if you fat-finger the sentence is the client that created it)? That issue is more than enough to get a NACK from me on making the current BIP39 draft a standard - I can easily see that leading to users losing a lot of money. Have any wallets implemented BIP39 this way already in released code? -- 'peter'[:-1]@petertodd.org 9c3092c0b245722363df8b29cfbb86368f4f7303e655983a -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.
Comments: bc: - Ultimately, this helps with block propagation latency, but not with the bandwidth constraints themselves, because all transactions do need to be broadcast. - Most of the benefits of your approach can be obtained simply by prebroadcasting the entire merkle tree while you're working on it. You can get even bigger gains by the miners reusing large chunks of each other's merkle trees (which they could if they had similar transaction selection policies). Then there's just the headers to broadcast. Natanael: - Most of the block's content is important though, because I don't just want to know that the block is valid, I also want to know what changes to make to my local copy of the UTXO. So I don't know how much space/bandwidth you'd save. You would definitely save on signature checking and independent validation, but that's CPU time. On Wed, Jan 22, 2014 at 4:43 PM, Natanael natanae...@gmail.com wrote: Couldn't we also use the type of zkSNARK's that Zerocoin adopted to prove that the hash-only blocks only have valid transactions in it, since they are small and quite efficient to verify? The trouble is that they're still inefficient to generate, but given powerful enough computers that compiles the hashes for the block and it could likely still be done fast enough to handle large amounts of transactions. The computer is likely not going to be the most expensive part anyway by a far margin. zkSNARK = zero-knowledge Succinct Non-interactive ARgument of Knowledge On Wed, Jan 22, 2014 at 10:06 PM, bc b...@bcdev.net wrote: Pdf version: http://bcdev.net/data/bitcoin_big_tx_with_coin_join.pdf == Combining big transactions with hash-only blocks to improve tps. == Abstract: I've heard people talk about including only hashes in a block to speed up the network and also about using CoinJoin to improve privacy. I've not heard anyone talk about implications of combining these two techniques. I think that it would both improve network's anonymity, but also improve tps by a few orders of magnitude. I propose two optimizations: 1. Keep only hashes of transactions included in a block. Transfer all tx separately. 2. Use CoinJoin to merge transactions from many users for online shopping and banking. 3. Use Jumbo transactions as a fallback for applications where CoinJoin is inappropriate. Keeping only hashes of tx in a block: Currently every bitcoin block includes a copy of all transactions. This is redundant and unnecessary, since after the transaction gets transmitted, every node learns about it in seconds. By keeping only transaction hashes in block, we can keep block propagation time from increasing. Assuming a typical tx with one or two inputs and two outputs [typically 300 bytes], current 1MiB block can contain about [assuming a block every 10 minutes]: 1MiB / 300 bytes = 3300tx = 5.5tps By keeping only hashes in a block [32 bytes per hash]: 1MiB / 32 bytes = 31000tx = 50tps == Benefits: == This method allows to achieve more tps without increasing the block propagation time, which is critical for mining decentralization. It removes redundancy, since every tx has to be transmitted only once. It leads to a more consistent bandwidth utilization [large transactions are transmitted all the time, while blocks are kept small and easy to propagate]. Because a block size is a constant, mining fees would not depend on the size of a transaction. Obviously to limit the network flood, there should be a transaction size limit. == Problems: == Selfish miner can keep a subset of transactions only for yourself and release them only with a new block. This problem can be mitigated by making nodes verify all transactions before propagating a block. The incentive will then be to mine only a well-distributed transactions to lower orphan rate. The miner can try to sneak up invalid transaction in a block. This problem is also mitigated by not accepting a block before it gets verified. CoinJoin: If the block size keeps only hashes, a transaction can be much bigger. Since CoinJoin allows many people to send coins with one transaction, the effective transaction rate can be increased considerably. == Example: == Let's assume the transaction size limit of 50KiB. Limit of this size allows for a CoinJoin transaction between 50KiB / 300b = 170 participants. So for a block of 1MiB, it would allow for 50tps * 170effective_transactions/tx = 8500tps. == Benefits: == There would be an incentive for users to use CoinJoin by default [lower tx fees per effective transaction], which would greatly increase anonymity of the network. Since block size stays the same, block propagation time also stays the same. It doesn't require any changes to the protocol. CoinJoin transactions were always supported in bitcoin. == Problems: == 1) CoinJoin requires collaboration between many users in real-time. It means, that transaction must be
Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.
Transactions are already sitting in everyone's (or nearly everyone's) mempools (because they get broadcast to get to a miner in the first place). If you don't have it (because you just connected to the network after stopping for a bit) you can just call getdata against your peers to get a copy. Not rebroadcasting the transactions as part of the blocks is already in the cards because it's such an easy way to cut network traffic nearly in half. On Wed, Jan 22, 2014 at 5:10 PM, Jorge Timón jti...@monetize.io wrote: Maybe I'm missing something. How do miners validate blocks if they only receive the hashes of the transactions? Will they mine on top of a block when they don't know if it's valid? On 1/22/14, Christophe Biocca christophe.bio...@gmail.com wrote: Comments: bc: - Ultimately, this helps with block propagation latency, but not with the bandwidth constraints themselves, because all transactions do need to be broadcast. - Most of the benefits of your approach can be obtained simply by prebroadcasting the entire merkle tree while you're working on it. You can get even bigger gains by the miners reusing large chunks of each other's merkle trees (which they could if they had similar transaction selection policies). Then there's just the headers to broadcast. Natanael: - Most of the block's content is important though, because I don't just want to know that the block is valid, I also want to know what changes to make to my local copy of the UTXO. So I don't know how much space/bandwidth you'd save. You would definitely save on signature checking and independent validation, but that's CPU time. On Wed, Jan 22, 2014 at 4:43 PM, Natanael natanae...@gmail.com wrote: Couldn't we also use the type of zkSNARK's that Zerocoin adopted to prove that the hash-only blocks only have valid transactions in it, since they are small and quite efficient to verify? The trouble is that they're still inefficient to generate, but given powerful enough computers that compiles the hashes for the block and it could likely still be done fast enough to handle large amounts of transactions. The computer is likely not going to be the most expensive part anyway by a far margin. zkSNARK = zero-knowledge Succinct Non-interactive ARgument of Knowledge On Wed, Jan 22, 2014 at 10:06 PM, bc b...@bcdev.net wrote: Pdf version: http://bcdev.net/data/bitcoin_big_tx_with_coin_join.pdf == Combining big transactions with hash-only blocks to improve tps. == Abstract: I've heard people talk about including only hashes in a block to speed up the network and also about using CoinJoin to improve privacy. I've not heard anyone talk about implications of combining these two techniques. I think that it would both improve network's anonymity, but also improve tps by a few orders of magnitude. I propose two optimizations: 1. Keep only hashes of transactions included in a block. Transfer all tx separately. 2. Use CoinJoin to merge transactions from many users for online shopping and banking. 3. Use Jumbo transactions as a fallback for applications where CoinJoin is inappropriate. Keeping only hashes of tx in a block: Currently every bitcoin block includes a copy of all transactions. This is redundant and unnecessary, since after the transaction gets transmitted, every node learns about it in seconds. By keeping only transaction hashes in block, we can keep block propagation time from increasing. Assuming a typical tx with one or two inputs and two outputs [typically 300 bytes], current 1MiB block can contain about [assuming a block every 10 minutes]: 1MiB / 300 bytes = 3300tx = 5.5tps By keeping only hashes in a block [32 bytes per hash]: 1MiB / 32 bytes = 31000tx = 50tps == Benefits: == This method allows to achieve more tps without increasing the block propagation time, which is critical for mining decentralization. It removes redundancy, since every tx has to be transmitted only once. It leads to a more consistent bandwidth utilization [large transactions are transmitted all the time, while blocks are kept small and easy to propagate]. Because a block size is a constant, mining fees would not depend on the size of a transaction. Obviously to limit the network flood, there should be a transaction size limit. == Problems: == Selfish miner can keep a subset of transactions only for yourself and release them only with a new block. This problem can be mitigated by making nodes verify all transactions before propagating a block. The incentive will then be to mine only a well-distributed transactions to lower orphan rate. The miner can try to sneak up invalid transaction in a block. This problem is also mitigated by not accepting a block before it gets verified. CoinJoin: If the block size keeps only hashes, a transaction can be much bigger. Since CoinJoin allows many people to send coins with one transaction, the effective transaction
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... If the only concern is to make scan-to-pay work without reliance on SSL's PKI, it might be better to specify the payment protocol url *and* the public key used for signing right in the qr code. The wallet connects to the url, fetches the payment request (maybe over a secure connection, maybe not, doesn't matter), and verifies the signature matches the public key from the qr code. Downsides compared to embedding the entire request: Payee needs to host/serve requests somewhere online. This introduces reliability and DoS concerns. Payer needs an internet connection to fetch the request. Advantages: Serve variable payment requests from the same qr code (improving recipient privacy). Still no hard dependency on CAs. Even if both CA and DNS are compromised by an attacker, the worst they can do is Denial of Service. Optionally use CAs so that the wallet can attach an identity to who you're paying by QR code. This partly addresses the problem of the waiter overwriting the QR code. A non-PKI transaction would simply show Unknown recipient. Much smaller QR code (only overhead is the key parameter, and you could use a boolean param + the address as public key hack Mike mentionned, for only 4 characters of overhead). No need for a backward-incompatible bitcoin: scheme On Mon, Jan 27, 2014 at 3:34 PM, Roy Badami r...@gnomon.org.uk wrote: On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote: On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach andr...@schildbach.de wrote: SCAN TO PAY For scan-to-pay, the current landscape looks different. I assume at least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded into a QR-code. Nevertheless, I tried to encode a payment request into the bitcoin URL. I used my existing work on encoding transactions into QR-codes. Steps to encode: Really interesting work. When using scan-to-pay, after the payer scans the QR code with the protobuf PaymentRequest (not a URL to download the PaymentRequest) are they using their own connectivity to submit the Payment response? If we assume connectivity on the phone, might as well just get a URL from the QR code and re-use existing infrastructure for serving that? My first thought was likewise. In the case where the phone needs Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL? I'm assuming that every client will have to support this is any case, since it's effectively mandated by the BIP, so why add another mode of operation? However, PaymentRequest-over-QR-code does seem to me to have one rather attractive advantage: the authentication model is orders of magnitude simpler and more intuitive for a face-to-face transaction than anything else. You're saying pay the coins to that thing over there displaying that QR code. Which, most of the time, is exactly what you want. In the web case, it's fine to ignore the case where the URL domain has been subverted (and an cert obtained by the attacker) because in that case you've lost before you even get to payments (MitM attacker shows you a modified web page with different payment details). But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... roy -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
The merchant can always act maliciously by simply not delivering the goods. The only recourse the payment protocol provides at that point is that you have proof the merchant is acting maliciously (or at the very least his payment system is broken). Your scheme just adds an ACK of the specific unsigned transactions before the payment is effectively irreversible. I can't come up with a situation where the combination of signed request and blockchain entry aren't enough evidence, yet where adding an ACK by the merchant of the unsigned transaction tips the balance the other way. If you know of such a possibility, I'd love to hear it, because we'd know what we're trying to fix. The only way I can see a malicious merchant exploiting wallet behaviour around PaymentACK is by accepting the Payment message, not broadcasting it, not returning an ACK, and hoping the wallet/user retries paying with a new, non-conflicting transaction. Then he can try milking multiple small payments out of the user before they realize what happened, and broadcast them all at once, stealing more funds than the user ever was willing to risk in the transaction. But this is trivial to guard against at the wallet level (by making every new payment conflict with all previous non-acked payments). The non-reliability of getting memo/refund fields is a separate problem, but it seems BitcoinJ's approach addresses that nicely. On Thu, Jan 30, 2014 at 11:16 PM, Chuck chuck+bitcoin...@borboggle.com wrote: On 1/31/2014 3:16 AM, Jeremy Spilman wrote: I think we want to separate the two issues; 1) Reliably getting refund/memo fields to the merchant/payee 2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and if/when they should be [double]-spent to clear them We should be able to solve '1' without having to fully spec out behavior for 2. My original message was focused on #1. Not only #1, but ensuring the merchant can't act maliciously too. As far as #2 is concerned, I don't think it makes any difference - it's in both the customer and the merchant's best interest to have the transactions confirmed. c) Send them as a response to the PaymentRequest/PaymentDetails with the UNsigned transaction, and then follow up with the signed transaction in a separate message. ... On Wed, 29 Jan 2014 21:47:51 -0800, Chuck chuck+bitcoin...@borboggle.com wrote: 3. Customer builds a set of transactions and sends a new PaymentApprovalRequest message which includes a refund address and the unsigned transactions and their associated fully-signed transactionhash, the whole message signed with the private key of the refund address. Unsigned transactions and their associated fully-signed transaction hash -- isn't that a fully signed transaction? In this case, it doesn't solve the core problem of the server being able to broadcast that transaction without ACKing. What I meant was (and maybe this was roundabout?): the customer includes the UNsigned transactions as well as the hashes (and only the hashes) of the fully signed transactions. The customer keeps the fully signed transactions private until the merchant ACKs the unsigned versions. If the merchant has the hash of the fully signed transaction, he can monitor the network for delivery of the signed transaction. It definitely complicates things, but it's nothing that can't be done. Cheers, Chuck -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: Canceling Payments
Over http, the merchant doesn't have the ability to reach out to the consumer's bitcoin wallet on their own. So sending Cancel Payment Request to the user is impossible. If the customer doesn't want to send, nothing ever needs to happen. So sending a Reject Payment Request to the merchant is useless. The unhappy path scenario with Payment Requests (customer paid, but for whatever reason that payment is no longer valid) can be simply solved in 1 of 2 ways: If the merchant realizes the mistake, they can refund the money. If the customer realizes the problem, they can contact the merchant, provide the signed request, and ask the merchant to return the funds. What isn't covered? On Mon, Feb 3, 2014 at 1:08 PM, Tim Tuxworth t...@go-taxi.biz wrote: The process described in BIP70 might be ok for a simple happy path scenario, but what if things don't work so smoothly. I'm not talking here about technical issues, but _very common_ business scenarios such as: e.g. Merchant cancels request before payment is sent, such as when:- - the merchant realizes that they charged the wrong amount - the merchant realizes that they send the payment request to the wrong customer ... e.g. the Merchant or Customer decides to cancel the transaction after the payment request is sent because:- - the customer decides to pay by some other mechanism like cash or credit/debit - the customer doesn't have sufficient funds and decides not to purchase - the customer changes their mind and decides not to purchase ... It strikes me that a Cancel Payment Request message is required and a Reject Payment Request may also be required (or maybe use the same message for both). Tim Tuxworth -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Given the enormous number of variations on time periods for a
recurring payment, might it be better to simple allow a list of
timestamps? It costs almost nothing, bandwidth wise, and shifts the
thinking to the merchant platform. That doesn't give you an infinite
time frame, but you just get a new list of timestamps every time you
pay the service.
Continuing that thought, is a next_payment_time field with each
incremental transaction enough to cover everything?
On Tue, Feb 25, 2014 at 1:40 PM, Drak d...@zikula.org wrote:
Forgive me if I missed it, but the spec doesnt look like it can handle only
handle periods of per week, per month, per quarter rather than 'n period'. I
take Paypal as a reference example for subscription payments where you can
set recurring to every: n days, n weeks, n months, n years. That way a
quarterly payment is every 3 months. This fine granularity is necessary
because sometime a payment scheme can be per 4 weekly rather than per
monthly.
So in summary the spec needs daily as an option, and to specify the
recurring cycle as every n*period (one of daily, weekly, monthly, yearly):
and you can drop quarterly since it's just expressed as per 3*monthly.
Drak
On 25 February 2014 16:29, Mike Hearn m...@plan99.net wrote:
Hey there,
So the essence of this protocol is as follows:
enum PaymentFrequencyType {
WEEKLY = 1;
MONTHLY = 2;
QUARTERLY = 3;
ANNUAL = 4;
}
message RecurringPaymentDetails {
// Namespace for the merchant such as org.foo.bar
required string merchant_id = 1;
// Id for the recurring subscription
required bytes subscription_id = 2;
// Contracts associated with a given subscription
repeated RecurringPaymentContract contracts = 3;
}
message RecurringPaymentContract {
// Unique id for a given contract
required bytes contract_id = 1;
// URL to poll to get the next PaymentRequest
required string polling_url = 2;
// Timestamp; when this contract starts
required uint64 starts = 3;
// Timestamp; when this contract should be considered invalid
optional uint64 ends = 4;
// Expected payment frequency
optional PaymentFrequencyType payment_frequency_type = 5;
// Max payment amount within that frequency (e.g. no more than 5
BTC per month)
optional uint64 max_payment_per_period = 6;
// Max payment amount (e.g. no more than 3 BTC per payment)
optional uint64 max_payment_amount = 7;
}
I have the following comments:
There's no need to serialize RecurringPaymentDetails as bytes here. It's
done that way outside of PaymentDetails in order to support digital
signatures over protobufs that may have extensions the wallet app isn't
aware of, but it's a pain and inside PaymentDetails (and therefore for most
extensions) it shouldn't be necessary. So you can just use optional
RecurringPamentDetails recurring_payments = 8;
There's only 4 possibilities here for recurrences. That seems rather
restrictive. Is the cost of being more expressive really so high? Why not
allow more flexible specification of periods?
If there's no payment_frequency_type field then what happens? A quirk of
protobufs to be aware of is that making an enum field required can hurt
backwards compatibility. Because it will be expressed using a languages
underlying enum type, if there's a new enum member added later old software
that attempts to deserialize this will throw exceptions because the new
unknown member would be unrepresentable in the old model. Making the field
optional avoids this problem (it will be treated as missing instead) but
means software needs to be written to know what to do when it can't read the
enum value / sees enum values from the future.
I assume the amounts are specified in terms of satoshi, and timestamps are
UNIX time, but better to make that explicit.
Seems there's an implicit value constraint that max_payment_amount =
max_payment_per_period. What happens if that constraint is violated? Best to
document that.
What's the merchant ID namespace thing about? What's it for? What
happens if I set my competitors merchant ID there?
What's the subscription ID? Is this stuff not duplicative/redundant with
the existing merchant_data field?
In what situations would you have 1 contract per payment request? I'm not
sure I understand why it's repeated. Presumably if there are zero contracts
included the data should be ignored, or an error thrown and the entire
payment request rejected? Which should it be?
It's unclear to me given such a contract when the payment should actually
occur. For instance if it's monthly then what day in the month would the
payment occur?
You'll notice I moved the comments to be above the field definitions. I
know the current proto isn't done that way, but let's change it - long
Re: [Bitcoin-development] bits: Unit of account
If you absolutely want a name for some small unit (which may be valuable, not knocking that part of the idea), please use anything other than bits, which is already a massively overloaded term that will confuse the hell out of people: Harddrive costs measured in bits per gigabyte? An itunes movie download that costs 200,000 bits and takes 804.2 megabytes of space? Or a 10-megabit internet connection costing 10,000,000 bits per month? It's especially bad given that bitcoin will likely be adopted first for online use, where the competing (and more recognized) meaning of bit is most prevalent. Not to mention the overlap within bitcoin itself, with people already using millibits in conversation as a shorthand for mBTC. Hence one new bit is exactly 1/1000 of the old millibit. Make something up if you have to, or just use satoshis. On Sun, Apr 20, 2014 at 10:28 AM, Tamas Blummer ta...@bitsofproof.com wrote: People on this list are mostly engineers who have no problem dealing with magnitudes and have rather limited empathy for people who have a problem with them. They also tend to think, that because they invented money 2.0 they would not need to care of finance’s or people’s current customs. The importance of their decisions in these questions will fade as people already use wallets other than the core. Bring this particular discussion elsewhere, to the wallet developer. BTW the topic was discussed here several times, you have my support and Jeff Garzik’s. Regards, Tamas Blummer http://bitsofproof.com On 20.04.2014, at 15:15, Rob Golding rob.gold...@astutium.com wrote: The average person is not going to be confident that the prefix they are using is the correct one, The use of any 'prefix' is one of choice and entirely unnecessary, and there are already established 'divisions' in u/mBTC for those that feel they need to use such things. people WILL send 1000x more or less than intended if we go down this road, Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3 dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not once in 20 years has anyone ever 'sent' more or less than intended - oh, they've 'intended' to underpay just fine, but never *unintended*. I propose that users are offered a preference to denominate the Bitcoin currency in a unit called a bit. Where one bitcoin (BTC) equals one million bits (bits) and one bit equals 100 satoshis. I propose that for people unable to understand what a bitcoin is, they can just use satoshi's and drop this entire proposal. Rob -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
Culturally neutral? bit in French phonetically collides with slang for phallus (bitte, with a silent e). Apparently it means louse in Turkish as well. Not that this really would be avoidable with any short word (all the short possible words are usually taken), but it's not neutral. On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger bitc...@olivere.de wrote: Hello, just my two 'cents': Terms arises by itself. Just as most people speak of coins when they mean bitcoins. I do not see that bitcoin is currently in common use except for speculation. Therefore no term for smaller units has established yet. No problem in my eyes. Time will tell. - oliver -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Just a few issues with the idea as it currently stands: 1. This provides a very strong incentive to always vote for reallocating a block if it isn't yours, regardless of whether it's bad or not (there's a positive expected return to voting to reallocate coinbases from other miners). The incentive is bigger the more hash power you have. You can partially address this by: a) Requiring supermajorities b) Requiring a vote to include proof of a double spend (that's not a very strong safeguard, since anyone can create them after the fact if one of their own transactions has been included). c) Burning, rather than reallocating, the coins. Miners' immediate incentive to attack honest pools is much reduced. 2. BitUndo gets paid using additional txouts in the double-spend transaction, no by miner's fees. This means that the coinbase transaction will represent a smaller and smaller share of their revenues over time (however if the total honest transaction fees they get in their block are high enough, the risk of losing those might still be enough). On Wed, Apr 23, 2014 at 3:55 AM, Mike Hearn m...@plan99.net wrote: Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. When they eventually find a block, they run to the merchant and pay, then broadcast the block. In a simpler variant of this attack you make purchases as normal with a modified wallet that always submits a double spend to the service, and then N% of the time where N is the percentage of overall hash power the dishonest miners have, you get your money back minus their fee. N does not need to be very high to render Bitcoin much less useful. Real time transactions are very important. Although I never expected it when I first started using Bitcoin, nowadays most of my purchases with it are for food and drink. If Bitcoin could not support such purchases, I would use it much less. Even with their woeful security many merchants see 1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population of users who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards. EMV transactions have loss rates in the noise, so for merchants who take those Bitcoin would be dramatically less secure. The idea of discouraging blocks that perform Finney attacks by having honest miners refuse to build on them has been proposed. But it has a couple of problems: It's hard to automatically detect Finney attacks. Looking for blocks that contain unseen transactions that override the mempool doesn't work - the dishonest users could broadcast all their double spends once a Finney block was found and then broadcast the block immediately afterwards, thus making the block look like any other would in the presence of double spends. If they could be automatically identified, it possibly could be converted into a DoS on the network by broadcasting double spends in such a way that the system races, and every miner produces a block that looks like a Finney attack to some of the others. The chain would stop advancing. Miners who want to vote no on a block take a big risk, they could be on the losing side of the fork and end up wasting their work. We can resolve these problems with a couple of tweaks: Dishonest blocks can be identified out of band, by having honest miners submit double spends against themselves to the service anonymously using a separate tool. When their own double spend appears they know the block is bad. Miners can vote to reallocate the coinbase value of bad blocks before they mature. If a majority of blocks leading up to maturity vote for reallocation, the value goes into a pot that subsequent blocks are allowed to claim for themselves. Thus there is no risk to voting no on a block, the work done by the Finney attacker is not wasted, and users do not have to suffer through huge reorgs. This may seem a radical suggestion, but I think it's much less radical than some of the others being thrown around. The above approach works as long as the majority of hashpower is honest, defined to mean, working to stop double spending. This is the same security property as described in the white paper, thus this introduces no new security assumptions. Note that assuming all miners are dishonest and are willing to double spend automatically resolves the Bitcoin experiment as a failure, because that would invalidate the entire theory upon which the system is built. That doesn't mean the assumption is wrong! It may be that an entirely unregulated market for double spending prevention cannot work and the participants eventually all end up trashing the commons - but the hope is that smart incentives can replace
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
It's not necessary that this coinbase retribution be either profitable or risk-free for this scheme to work. I think we should separate out the different layers of the proposal: 1. Attacking the coinbase instead of orphaning allows for 100 blocks' time for a consensus to be reached, rather than 10 minutes. This allows for human verification/intervention if needed (orphaning decisions would almost always need to be automated, due to the short timeframe). This is a useful insight, and I don't think it's been brought up before. 2. The original specification of how it's done (redistribution, no cost to voting) does seem exploitable. This can be fixed by reducing the incentive (burning instead of redistributing) and/or adding a risk to the orphaning attempts (a vote that fails destroys X bitcoins' worth from each voting block's own coinbase). The incentives can be tailored to mirror those of orphaning a block, to reduce the risk of abuse. Then the only difference from orphaning are 1) More limited rewriting of history (only the coinbase, vs all transactions in the block), and 2) More time to coordinate a response. 3. This proposal may be used for things other than punishing double-spend pools. In fact it might be used to punish miners for doing anything a significant percentage of hashpower dislikes (large OP_RETURNs, large blocks, gambling transactions, transactions banned by a government). But we can make the threshold higher than 51%, so that this doesn't turn into a significant risk (if 75% of hashpower is willing to enforce a rule, we're already likely to see it enforced through orphaning). On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: And it still would. Non-collusive miners cast votes based on the outcome of their own attempts to double spend. Individually rational strategy is to vote for coinbase reallocation on every block. Yes, in that case nobody will get reward. It is similar to prisoner's dilemma: equilibrium has worst pay-off. In practice that would mean that simple game-theoretic models are no longer applicable, as they lead to absurd results. I'm using it in the same sense Satoshi used it. Honest miners work to prevent double spends. That's the entire justification for their existence. Miners that are deliberately trying to double spend are worse than useless. Miners work to get rewards. It absolutely doesn't matter whether they are deliberately trying to double-spend or not: they won't be able to double-spend without a collusion. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. I actually agree that this is a problem, but that's actually not inherent in the proposed enforcement mechanism (just the current voting rules). Here's an alternate: - To start a vote, you set aside a part of your coinbase with amount X = their entire coinbase amount. - Then you need 51 blocks with a yes vote before the coinbase maturity of the target for the vote to be considered a success. - Success means target coinbase has X coins reallocated/burned. - Failure means vote-initiating coinbase has X coins reallocated/burned. The incentives for voting miners are to vote yes if and only if they dislike the targeted miner more than the initiator (all other monetary effects are identical). That isn't a bulletproof way to force miners to only punish double spenders (rather than anything they dislike in general), but it removes the risk free nature of trying to take away another miner's coinbase. It means that you'll need a high level of confidence other miners are on your side before taking a risk, but, because you've got a much longer time frame than 10 minutes, you can get manual confirmation from other miners. On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd p...@petertodd.org wrote: On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote: Actually Peter, coinbase confiscations are a much worse mechanism for enforcement of widespread censorship rules than simple orphaning. They lose their power when the transaction miners are punished for can build up over time without losing their usefulness: snip Of course, in such a dystopian future, orphaning would be the enforcement mechanism. It would be stupid to rely on coinbase reallocation/burning to do this task when the existing tools work so much better. I don't disagree with you at an end stage, but the thing with coinbase blacklists/confiscation is because it's a voting mechanism the initial stages of enforcing widespread censorship rules with it are much easier. For instance, if a 10% pool that has been forced/wants to blacklist certain transactions can do so, and then vote to blacklist blocks that do not abide by that blacklist. Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. At some point they will reach a majority, which causes the blacklist to actually apply. The whole process happens smoothly, letting the blacklist be applied safely and easily. With orphaning/reorging on the other hand you just can't be sure that the other miners will actually adopt it, making adoption risky. Of course, that's above and beyond the fact that you can't prove a Finney attack happened to a third-party, making it easy to attack smaller miners with Sybil attacks, get them creating blocks with double-spends in them, and using that as an excuse to punish them. What's interesting is that this mechanism is especially tailored to blocking time sensitive transactions (that need to be confirmed now/soon, or are worthless), such that their total out-of-band fees can't build up over time. Double spending is one such category. I'm at a loss to come up with something else, but maybe someone has a good example? Decentralized markets are a great example: the bids and orders they depend on are time-senstive and become much less valuable if they get delayed greatly. -- 'peter'[:-1]@petertodd.org 091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
This seems like splitting hairs, no? A block isn't a guarantee (it can get orphaned). And as a user of bitcoin (as opposed to a miner), this change cannot affect any payment you ever receive. Some of the interpretation is already different for coinbase UTXO's (need a valid height, locked for 100 blocks). Anyone expecting them to behave like any other UTXO will get bitten by one of those subtleties (MtGox's withdrawals had issues with exactly this, IIRC). On Sat, Apr 26, 2014 at 8:15 AM, Gareth Williams gac...@gmail.com wrote: On 26/04/14 01:28, Mike Hearn wrote: When you have a *bitcoin* TXn buried under 100 blocks you can be damn sure that money is yours - but only because the rules for interpreting data in the blockchain are publicly documented and (hopefully) immutable. If they're mutable then the PoW alone gives me no confidence that the money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit. Well, I think we should avoid the term sacred - nothing is sacred because we're not building a religion here, we're engineering a tool. Are you sure there isn't room for just a touch of religion? :) As you state below, all that protects my money from confiscation is strong group consensus that it's mine - a social rule, not a mathematical one. Everything ultimately balances on that. People being a little bit religious about following the protocol faithfully are the linchpin of Bitcoin security, not PoW. Consider a world in which 1 satoshi is too valuable to represent some kinds of transactions, so those transactions stop happening even though we all agree they're useful. The obvious solution is to change the rules so there can be 210 million coins and 10x everyones UTXOs at some pre-agreed flag day. We probably wouldn't phrase it like that, it's easier for people to imagine what's happening if it's phrased as adding more places after the decimal point or something, but at the protocol level coins are represented using integers, so it'd have to be implemented as a multiply. Agree. Would this be a violation of the social contract? A violation of all that is sacred? I don't think so, it'd just be sensible engineering and there'd be strong consensus for that exactly because 21 million /is/ so arbitrary. If all balances and prices multiply 100-fold overnight, no wealth is reallocated which would be the /actual/ violation of the social contract: we just get more resolution for setting prices. Wholeheartedly agree. 21 million is just shorthand for the preservation of artificial scarcity. No rational person could argue that what you described violates the social contract. I do see what you're driving at - that there exists a situation where it would be justified to change the interpretation of data in existing blocks. But, please consider: if I controlled a single UTXO worth 1% of the total money supply before your change, the network would still recognise that I control a single UTXO worth 1% of the total money supply after your change. So you haven't really changed the interpretation of existing blocks at all there. It's just semantics :) Contrast this with invalidating a coinbase before maturity, which clearly has a very real impact. At the point the vote passes, you're *** sidestepping the PoW mechanism and rewriting the meaning of an existing, validated block ***. So. The thing that protects your money from confiscation is not proof of work. PoW is just a database synchronisation mechanism. The thing that protects your money from confiscation is a strong group consensus that theft is bad. But that's a social rule, not a mathematical rule. Agree. That's my whole point :) I recognise my security is in the hands of the users (the economic majority.) Tomorrow they could all decide to patch their nodes to reallocate my UTXOs, and there's not a damn thing I could do about it, PoW and private keys notwithstanding. I must simply trust that they will not do this. So we can have: 1. Neutral Bitcoin, where everyone is committed to prevention of theft by following a simple set of mathematical rules which treat all validated blocks as equal. Or: 2. Political Bitcoin, where everyone is committed to prevention of theft based on human judgements, and the contents of some validated blocks are more equal than others. I recognise that the latter allows for a lot of flexibility in combating fraud, but with (substantial) due respect, it isn't Bitcoin. -Gareth -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform
Re: [Bitcoin-development] bits: Unit of account
Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine vois...@gmail.com wrote: I have to agree with Mike. Human language is surprisingly tolerant of overloading and inference from context. Neurotypical people have no problem with it and perceive a software engineer's aversion to it as being pedantic and strange. Note that bits was a term for a unit of money long before the invention of digital computers. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr goj...@gmail.com wrote: [resend - apologies if duplicate] Microbitcoin is a good-sized unit, workable for everyday transaction values, with room-to-grow, and a nice relationship to satoshis as 'cents'. But bits has problems as a unit name. Bits will be especially problematic whenever people try to graduate from informal use to understanding the system internals - that is, when the real bits of key sizes, hash sizes, and storage/bandwidth needs become important. The bit as binary digit was important enough that Satoshi named the system after it; that homage gets lost if the word is muddied with a new retconned meaning that's quite different. Some examples of possible problems: * If bit equals 100 satoshis, then the natural-language unpacking of bit-coin is 100 satoshi coin, which runs against all prior usage. * If people are informed that a 256-bit private key is what ultimately controls their balances, it could prompt confusion like, if each key has 256-bits, will I need 40 keys to hold 10,000.00 bits? * When people learn that there are 8 bits to a byte, they may think, OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes. * When people naturally extend bit into kilobits to mean 1000 bits, then the new coinage kilobits will mean the exact same amount (100,000 satoshi) as many have already been calling millibits. I believe it'd be best to pick a new made-up single-syllable word as a synonym for microbitcoin, and I've laid out the case for zib as that word at http://zibcoin.org. 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ' (Z-with-stroke), that remains distinctive even if it loses its stroke or gets case-reversed. (Comparatively, all 'b'-derived symbols for data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts where subtleties of casing/stroking are lost.) (There's summary of more problems with bit in the zibcoin.org FAQ at: http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins.) - Gordon On 5/1/14, 3:35 PM, Aaron Voisine wrote: I'm also a big fan of standardizing on microBTC as the standard unit. I didn't like the name bits at first, but the more I think about it, the more I like it. The main thing going for it is the fact that it's part of the name bitcoin. If Bitcoin is the protocol and network, bits are an obvious choice for the currency unit. I would like to propose using Unicode character U+0180, lowercase b with stroke, as the symbol to represent the microBTC denomination, whether we call bits or something else:
Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk
Unfortunately this could fork the network permanently, which is much worse than a double spend. There's no magic way to have a consensus, so it becomes trivial with a few tries to split the network into two halves: (tx1 before tx2, tx2 before tx1). Some nodes in the middle will accept either block, but you've still forked off some non-zero number of nodes. At a minimum, you'd need a way to reconcile the split (Accept the offending block once it's 2+ deep). The problem is that since the rule isn't enforceable, no miner will wait before mining on the longest chain (which is the rational move), and you're back to where we are now. On Sat, May 3, 2014 at 8:29 PM, Tom Harding t...@thinlink.com wrote: This idea was suggested by Joe on 2011-02-14 https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484 . It deserves another look. Nodes today make a judgment regarding which of several conflicting spends to accept, and which is a double-spend. But there is no incorporation of these collective judgments into the blockchain. So today, it's the wild west, right up until the next block. To address this: - Using its own clock, node associates a timestamp with every transaction upon first seeing its tx hash (at inv, in a block, or when created) - Node relays respend attempts (subject to anti-DOS rules, see github PR #3883) - Eventually, node adds a consensus rule: Do not accept blocks containing a transaction tx2 where - tx2 respends an output spent by another locally accepted transaction tx1, and - timestamp(tx2) - timestamp(tx1) T What is T? According to http://bitcoinstats.com/network/propagation/ recent tx propagation has a median of 1.3 seconds. If double-spender introduces both transactions from the same node, assuming propagation times distributed exponentially with median 1.3 seconds, the above consensus rule with reject threshold T = 7.4 seconds would result in mis-identification of the second-spend by less than 1% of nodes.* If tx1 and tx2 are introduced in mutually time-distant parts of the network, a population of nodes in between would be able to accept either transaction, as they can today. But the attacker still has to introduce them at close to the same time, or the majority of the network will confirm the one introduced earlier. Merchant is watching also, and these dynamics mean he will not have to watch for very long to gain confidence if he was going to get double-spent, he would have learned it by now. The consensus rule also makes mining a never-broadcast double-spend quite difficult, because the network assigns it very late timestamps. Miner has to get lucky and find the block very quickly. In other words, it converges to a Finney attack. This would be the first consensus rule that anticipated less than 100% agreement. But the parameters could be chosen so that it was still extremely conservative. Joe also suggested a fail-safe condition: drop this rule if block has 6 confirmations, to prevent a fork in unusual network circumstances. We can't move toward this, or any, solution without more data. Today, the network is not transparent to double-spend attempts, so we mostly have to guess what the quantitative effects would be. The first step is to share the data broadly by relaying first double-spend attempts as in github PR #3883. *Calcs: For Exp(lambda), median ln(2)/lambda = 1.3 == lambda = .533 Laplace(0,1/lambda) .01 == T = 7.34 seconds -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Someone put a virus signature into the blockchain
Here's the relevant github issue: https://github.com/bitcoin/bitcoin/issues/4069 On Fri, May 16, 2014 at 10:22 AM, David Shares davidsha...@outlook.com wrote: http://www.reddit.com/r/Bitcoin/comments/25otbt/someone_put_a_virus_signature_in_the_bitcoin/ I just wanted to pass this into the dev list, in case it hasn't been seen yet. I haven't seen anything about it. Thanks, David. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
If your threat model is passive listeners, it seems to me that simply establishing a symmetric key for each connection at handshake time using diffie-hellman is all you need. No public private crypto needed at all. The whole thing seems like a bit of security theater unfortunately. The kind of attacker that can pull off widespread passive listening is probably able and willing to do active MITM. It's not a huge incremental cost. Instead, those users that do have a need for security should probably connect to the network using Tor or I2P, which can give much better security guarantees than anything being discussed here. On Tue, Aug 19, 2014 at 12:58 PM, Angel Leon gubat...@gmail.com wrote: I suggest that Bitcoin Core should generate a public/private key pair and share the public one with peers. I've not read the p2p protocol of Bitcoin core, but I suppose the initial handshake between 2 peers would be the ideal place to exchange a public keys. would it make sense to generate a new random pair of keys per each peer you connect to? then each subsequent message to every peer gets encrypted differently, keeping each conversation isolated from each other encryption-speaking. These keys would have nothing to do with your wallet, they're just to encrypt any further communication between peers post-handshake. Would that be of any use to This could provide privacy and integrity but not autentication.? http://twitter.com/gubatron On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier justusranv...@riseup.net wrote: If that's not acceptable, even using TLS with self-signed certificates would be an improvement. TLS is a huge complex attack surface, any use of it requires an additional dependency with a large amount of difficult to audit code. TLS is trivially DOS attacked and every major/widely used TLS implementation has had multiple memory disclosure or remote execution vulnerabilities even in just the last several years. We've dodged several emergency scale vulnerabilities by not having TLS. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
What hash function would you recommend? Due to the properties of hash functions, you can just take the first x bits of a SHA256 sum and they're pretty much as good as an equally secure hash function of that length. In fact SHA512/224 and SHA512/256 are defined in that way (Plus different initial values because you might as well do that when defining a standard). On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach andr...@schildbach.de wrote: On 09/12/2014 03:49 PM, Mike Hearn wrote: (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 force, whilst keeping QR codes more compact, which impacts scannability. To put that into perspective, here is how a bitcoin: URI would look like: bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhEr=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest (obviously for real-world usage you would optimize the r parameter) I looked at the list in this doc to evaluate what's easily available: https://code.google.com/p/guava-libraries/wiki/HashingExplained I thought SHA1 has a bad reputation these days, and we don't save much by using it. I don't know anything about Murmur. MD5 is clearly broken. What hash function would you recommend? (2) This should *not* be necessary in the common HTTPS context. It is. People can't check names. People don't want to check names. People can't get certificates for lots of reasons. X.509 is centralized. X.509 has had serious security issues in the past. And shit continues to happen. To sum up, X.509 can't replace the trust anchor that is established by scanning a QR code or tapping two devices together. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. Sure. But signing is harder than just calculating a hash. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
Specifically relevant here: http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits. If you're going to truncate though, why not just leave the amount of bits up the the person generating the QR code? The client simply takes the hash prefix (any length up to full 256-bits) and makes sure it's a strict prefix of the actual hash of the payment request. That way we leave up to implementers to experiment with different lengths and figure out what the optimum is (which could depend on the security/convenience tradeoff of that particular transaction, as in more bits for large payments). On Fri, Sep 12, 2014 at 11:25 AM, Christophe Biocca christophe.bio...@gmail.com wrote: What hash function would you recommend? Due to the properties of hash functions, you can just take the first x bits of a SHA256 sum and they're pretty much as good as an equally secure hash function of that length. In fact SHA512/224 and SHA512/256 are defined in that way (Plus different initial values because you might as well do that when defining a standard). On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach andr...@schildbach.de wrote: On 09/12/2014 03:49 PM, Mike Hearn wrote: (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 force, whilst keeping QR codes more compact, which impacts scannability. To put that into perspective, here is how a bitcoin: URI would look like: bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhEr=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest (obviously for real-world usage you would optimize the r parameter) I looked at the list in this doc to evaluate what's easily available: https://code.google.com/p/guava-libraries/wiki/HashingExplained I thought SHA1 has a bad reputation these days, and we don't save much by using it. I don't know anything about Murmur. MD5 is clearly broken. What hash function would you recommend? (2) This should *not* be necessary in the common HTTPS context. It is. People can't check names. People don't want to check names. People can't get certificates for lots of reasons. X.509 is centralized. X.509 has had serious security issues in the past. And shit continues to happen. To sum up, X.509 can't replace the trust anchor that is established by scanning a QR code or tapping two devices together. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. Sure. But signing is harder than just calculating a hash. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] From block 0 to block 72499 the Merkle root is the same as the coinbase transaction id. Why is that?
1. Not all of them (just the ones that have a coinbase transaction and nothing else). 2. The merkle root of a tree with just one item is the hash of that item. On Sat, Sep 20, 2014 at 11:38 AM, Peter Grigor pe...@grigor.ws wrote: -- Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: death by halving
The fact that it is known in advance is no counter argument to me. But it does change miner behaviour in pretty significant ways. Unlike difficulty forecasting, which seems near impossible to do accurately, miners can plan to purchase less hardware as they approach the revenue drop. You can do some basic cost/benefit calculation and see that *if* margins are already low as the halving approaches, then rational miners would cease purchasing any new hardware that wouldn't be profitable past that point, unless they expect it to pay for itself by then. The lower the margins are, the longer in advance they would alter their buying behaviour. You'd see an increased focus on cost-effective hashpower (and older units would not be replaced as they break). Either a significant supply of cost effective hardware shows up (because it's the only thing that would sell in the last months), or difficulty would stall long before the halving happens. Either way, the predictability of the halving can reduce the hashpower on the day. On Tue, Oct 28, 2014 at 5:34 PM, Neil kyuupic...@gmail.com wrote: Economically a halving is almost the same as a halving in price (as fees take up more of the pie, less so). Coincidentally the price has halved since early July to mid-October, and we've not even seen difficulty fall yet. I don't think there's much to see here. Neil -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
