Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On 06/18/2015 06:33 PM, Mark Friedenbach wrote: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. One of my biggest concerns is that these solutions (lightning network in particular) could end up being worse, in terms of decentralization, than would be a bitcoin network using larger blocks. We don't exactly know what the economies of scale are for pay hubs and could very well end up with far fewer hubs than nodes at any conceivable block size. Of course, it could also turn out to be fantastic, but it seems like an enormous gamble to basically force everyone in the ecosystem to collectively spend millions of dollars upgrading to Lightning /and then/ see whether it's actually an improvement in terms of decentralization. To me, a much more sane approach would be to allow people to voluntarily opt in to those other solutions after we've had an opportunity to experiment with them and see how they actually function in practice, but that can't happen if the network runs out of capacity first. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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. The downside is it relies entirely on Tor for privacy, but then again it's not the only aspect of spv clients that require it for privacy (there's broadcasting for example). And on a related note, if we eventually do end up receiving bip70 payments directly, we still need to query for block inclusion and that would seem to be an easy way to do it. On 02/20/2015 12:53 PM, Mike Hearn wrote: 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 bloom commitment (and UTXO trie organised commitment) he can verify that the positive hits are correct via the merkle path, and that the false positives are not being wrongly withheld by obtaining merkle path proof that they are not in the trie -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bloom filtering, privacy
Yeah that overhead is pretty high. I wasn't thinking about 10 years out.
On Sat, Feb 21, 2015, 11:47 AM Mike Hearn m...@plan99.net wrote:
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 growing. Let's imagine a system 10x larger than today. Doesn't
seem implausible to reach that in the next 5-10 years, so 15,000
transactions. Each transaction has multiple elements we might want to match
(addresses, keys, etc).
Let's say the average tx contains 5 unique keys/elements. That's the base
case of {1 input, 2 outputs} without address reuse, plus fudged up a bit
for multi-sends then down a bit again for address reuse.
15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get:
http://hur.st/bloomfilter?n=75000p=0.001
131.63KB per block extra overhead.
144 blocks in a day, so that's 18mb of data per day's worth of sync to
pull down over the network. If you don't start your wallet for a week
that's 126 megabytes of data just to get started.
Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I
don't believe that even in five years mobiles will be pulling down and
processing that much data within a few seconds, not even in developed
countries.
But like I said, I don't see why it matters. Anyone who is watching the
wire close to you learns which transactions are yours, still, so it doesn't
stop intelligence agencies. Anyone who is running a node learns which
transactions in the requested block were yours and thus can follow the tx
chain to learn which other transactions might be yours too, no different to
today. If you connect to a single node and say give me the transactions
sending money to key A in block N, it doesn't matter if you then don't
request block N+6 from the same peer - they know you will request it
eventually anyway, just by virtue of the fact that one of the transactions
they gave you was spent in that block.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On Nov 17, 2014 7:39 AM, Pieter Wuille pieter.wui...@gmail.com wrote: That is inevitable for any wallet that offers any functionality beyond just maintaining a balance and the ability to send coins. In particular, anything that wishes to list previous transaction (with timestamps, history, metadata, messages sent using t What HD wallets (or any type of deterministic derivation scheme) offer is the fact that you can separate secret data and public data. You only need one safe backup of the master secret key - all the rest can at most result in privacy loss and not in lost coins. -- Pieter I agree but right now wallets not using stealth will only lose metadata, not coins, if their computer crashes and they have the seed backed up. But if a user wants to upgrade to stealth, they then risk losing metadata AND coins if they either didn't manually back up after every transaction or use a centralized cloud backup service. That's if OP_RETURN is not utilized for storage. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On 11/17/2014 06:20 AM, Adam Back wrote: b) backup: the blockchain is not an efficient reliable generic backup mechanism because its broadcast. there are cheaper and relatively simple ways to get end2end secure backup, the main challenge of which is having secure keys and not forgetting them. bitcoin already has that covered as its a central requirement of blockchain security. If you want to archive your payment protocol receipts store them on some cloud storage service or disk encrypted with related keys. for example tahoe-lafs is optimised for the decentralised long-term storage kind of use. This is my main concern in the context of stealth addresses. I intend to start a larger discussion on stealth addresses, but I wont hijack the tread. Of course it's easy to send the necessary data out of band as opposed to OP_RETURN. The problem is if you do that the transaction cannot not be recovered from seed. We've been fairly successful in transitioning to HD wallets and avoiding the need to make regular wallet backups. If users wishes to use stealth addresses with out of band communication, the benefits of HD would largely be lost and they would be back to making regular backups ― this time after /every/ transaction rather than every 100. There are only a couple options in such cases: 1) The user could send the payment to an addresses that is derived from seed, but now you're using even /more/ storage space than you would by just using OP_RETURN. 2) The user can backup after every transaction, which nobody wants to do. 3) The user could use some form of a cloud backup service and place trust in them that their servers wont go down and lose their coins. None of those options are really that appealing. OP_RETURN seems like the best alternative to me, at least for that use case. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Update on mobile 2-factor wallets
Thanks Mike I'll have to read that threshold signature paper. 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? I would have concerns about generating a key on a compromised computer. On Nov 8, 2014 11:05 AM, Mike Hearn m...@plan99.net wrote: 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) smartphone app to go with them. Compromise of the wallet requires compromise of both devices. Alon Muroch and Chris Pacia have made huge progress on Bitcoin Authenticator, their (HD) wallet app. The desktop side runs on Win/Mac/Linux and the mobile side runs on Android. Sending money from the desktop triggers a push notification to the mobile side, which presents the transaction for confirmation. Additionally the desktop wallet has a variety of other features like OneName integration. It's currently in alpha, but I suspect it will be quite popular once released due to its focus on UI and the simple mobile security model. I've tried it out and it worked fine. https://www.bitcoinauthenticator.org/ https://github.com/cpacia/BitcoinAuthenticator/commits/master(mobile) https://github.com/negedzuregal/BitcoinAuthWallet (desktop) Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor functionality. However, this has various downsides that are well known: less support for the address type and larger transactions that waste block chain space + result in higher fees. To solve this problem Christopher Mann and Daniel Loebenberger from Uni Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA, and implemented their own desktop/Android wallet app pair showing that it works and has good enough performance. This means that P2SH / CHECKMULTISIG is no longer required for the two factor auth case, and thus it's as cheap as using regular addresses. https://github.com/ChristopherMann/2FactorWallet https://eprint.iacr.org/2014/629.pdf Their protocol uses an interesting combination of ECDSA, Paillier homomorphic encryption and some zero knowledge proofs to build a working solution for the 2-of-2 case only. Their app bootstraps from a QR code that includes a TLS public key and IP address of the desktop: the mobile app then connects to it directly, renders the transaction and performs the protocol when the user confirms. The protocol is online, so both devices must be physically present. Their code is liberally licensed and looks easy to integrate with Alon and Chris' more user focused work, as both projects are built with Android and the latest bitcoinj. If someone is interested, merging Christopher/Daniel's code into the bitcoinj multisig framework would be a useful project, and would make it easier for wallet devs to benefit from this work. I can write a design doc to follow if needed. Currently, neither of these projects implement support for BIP70, so the screen you see when signing the transaction is hardly user friendly or secure: you just have to trust that the destination address you're paying to isn't tampered with. Support for sending a full payment request between devices is the clear next step once these wallets have obtained a reasonable user base and are stable. -- ___ 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] CoinShuffle: decentralized CoinJoin without trusted third parties
One issue I do see is the protocol requires participants to check the inputs submitted by others are valid. Lite clients (at least of the p2p variety) cannot perform this check. You could skip the verification part and if the inputs turn out to be invalid then you'll find out when it doesn't confirm. This would problem open the protocol up to dos attacks and prevent part of the blame phase from working properly. Alternatively you can have the participants submit the merkle proof for the input. This would require inputs to have at least one confirmation, however. On Aug 6, 2014 6:42 PM, Tim Ruffing tim.ruff...@mmci.uni-saarland.de wrote: Hey, We (a group of researchers in Germany) propose a decentralized protocol for CoinJoin, a way to mix coins among users to improve anonymity. Our protocol is called CoinShuffle. We believe that CoinShuffle is a way to implement CoinJoin in the original spirit of Bitcoin, i.e., decentralized and without trusted third parties. (If you are not familiar with CoinJoin, the idea is explained here: https://bitcointalk.org/index.php?topic=279249.0 ) The protocol is essentially a clever way to create a CoinJoin transaction. Recall that the idea of CoinJoin is mixing with one SINGLE transaction that has multiple input addresses and multiple fresh output addresses (i.e., one pair of addresses per user). The advantage of CoinJoin over mixing with a server or trusted party is that nobody can steal coins. Each user can check if the single transaction sends enough coins to his fresh output address. If this is not the case, the user can just refuse to sign the transaction and nothing (bad) happens. The difficulty in CoinJoin is to let the participants announce their fresh output addresses without breaking anonymity: Of course, if a participant of the protocol just announces I have 1 BTC at address X now and I would like to have it back at address Y, then everybody can link X and Y and mixing is useless. A naive approach is to send these two messages via a secure channel to a server that organizes the whole mixing. While the server cannot steal coins, the server still has to be trusted for anonymity, because it knows which input addresses belong to which output addresses. We present the list of CoinShuffle's features at the end of this e-mail. An overview over the technical details can be found on the project page: http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/ Moreover, for the full details, have a look at the research paper on CoinShuffle that can be found here: http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf The paper has been accepted at a major European academic conference on security (ESORICS). We will present the idea there. Our Proof-of-concept Implementation --- There is a proof-of-concept implementation (written in Python) available on our project page. It is really only a proof-of-concept and it implements only the announcement of the addresses, not the creation of the transaction. Moreover, the code is CERTAINLY INSECURE and not well-written; our only goal was to demonstrate feasibility and estimate the performance of our approach. Our Future Plans Now we are planning a full, open-source implementation of the protocol. Of course, we would like to build on top of an existing wide-spread client. Since we do not have much experience in the design of existing Bitcoin clients, we would appreciate any help in the process. In particular, we did not decide which of the existing clients we would like to extend. Any hints towards this decisions would very helpful. Help in design and coding would be great but we also would like to hear your comments, criticism, and improvements for the protocol itself. CoinShuffle Features CoinShuffle has the following features: - Decentralization / no third party: There is no (trusted or untrusted) third party in a run of the protocol. (Still, as in all mixing solutions, users need some way to gather together before they can run the protocol. This can be done via a P2P protocol if a decentralized solution is desired also for this step.) - Unlinkability of input and output addresses: Nobody, in particular no server (there is none!), can link input and output addresses of a mixing transaction, as long as there are at least two honest participants in run of the protocol. (This is not a weakness: If there is only one honest participant, meaningful mixing is just impossible, no matter how it is organized. If all the other participants collude, they know all their input and output addresses and can immediately determine the output address of the honest participant.) - Security against thefts: As explained above, nobody can steal coins during the mixing because of the CoinJoin principle. Every participant can verify that his money will not be stolen.
Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties
Actually getUTXO would probably work here as well. It isn't authenticated but it should be good enough for this purpose. The worst that would happen is the tx doesn't confirm. On Aug 11, 2014 2:25 AM, Chris Pacia ctpa...@gmail.com wrote: One issue I do see is the protocol requires participants to check the inputs submitted by others are valid. Lite clients (at least of the p2p variety) cannot perform this check. You could skip the verification part and if the inputs turn out to be invalid then you'll find out when it doesn't confirm. This would problem open the protocol up to dos attacks and prevent part of the blame phase from working properly. Alternatively you can have the participants submit the merkle proof for the input. This would require inputs to have at least one confirmation, however. On Aug 6, 2014 6:42 PM, Tim Ruffing tim.ruff...@mmci.uni-saarland.de wrote: Hey, We (a group of researchers in Germany) propose a decentralized protocol for CoinJoin, a way to mix coins among users to improve anonymity. Our protocol is called CoinShuffle. We believe that CoinShuffle is a way to implement CoinJoin in the original spirit of Bitcoin, i.e., decentralized and without trusted third parties. (If you are not familiar with CoinJoin, the idea is explained here: https://bitcointalk.org/index.php?topic=279249.0 ) The protocol is essentially a clever way to create a CoinJoin transaction. Recall that the idea of CoinJoin is mixing with one SINGLE transaction that has multiple input addresses and multiple fresh output addresses (i.e., one pair of addresses per user). The advantage of CoinJoin over mixing with a server or trusted party is that nobody can steal coins. Each user can check if the single transaction sends enough coins to his fresh output address. If this is not the case, the user can just refuse to sign the transaction and nothing (bad) happens. The difficulty in CoinJoin is to let the participants announce their fresh output addresses without breaking anonymity: Of course, if a participant of the protocol just announces I have 1 BTC at address X now and I would like to have it back at address Y, then everybody can link X and Y and mixing is useless. A naive approach is to send these two messages via a secure channel to a server that organizes the whole mixing. While the server cannot steal coins, the server still has to be trusted for anonymity, because it knows which input addresses belong to which output addresses. We present the list of CoinShuffle's features at the end of this e-mail. An overview over the technical details can be found on the project page: http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/ Moreover, for the full details, have a look at the research paper on CoinShuffle that can be found here: http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf The paper has been accepted at a major European academic conference on security (ESORICS). We will present the idea there. Our Proof-of-concept Implementation --- There is a proof-of-concept implementation (written in Python) available on our project page. It is really only a proof-of-concept and it implements only the announcement of the addresses, not the creation of the transaction. Moreover, the code is CERTAINLY INSECURE and not well-written; our only goal was to demonstrate feasibility and estimate the performance of our approach. Our Future Plans Now we are planning a full, open-source implementation of the protocol. Of course, we would like to build on top of an existing wide-spread client. Since we do not have much experience in the design of existing Bitcoin clients, we would appreciate any help in the process. In particular, we did not decide which of the existing clients we would like to extend. Any hints towards this decisions would very helpful. Help in design and coding would be great but we also would like to hear your comments, criticism, and improvements for the protocol itself. CoinShuffle Features CoinShuffle has the following features: - Decentralization / no third party: There is no (trusted or untrusted) third party in a run of the protocol. (Still, as in all mixing solutions, users need some way to gather together before they can run the protocol. This can be done via a P2P protocol if a decentralized solution is desired also for this step.) - Unlinkability of input and output addresses: Nobody, in particular no server (there is none!), can link input and output addresses of a mixing transaction, as long as there are at least two honest participants in run of the protocol. (This is not a weakness: If there is only one honest participant, meaningful mixing is just impossible, no matter how it is organized. If all the other participants collude, they know all their input and output addresses and can
Re: [Bitcoin-development] Paper Currency
Since these notes have to be redeemed immediately the number of use cases seems limited. I can't really just hand someone the note and walk away because they have to scan it to see if it is actually valid. Otherwise someone could just pass fake notes if they felt the recipient wouldn't redeem them on the spot. This doesn't seem like an improvement over just sending the coins via phone. The use case with poor internet connection wouldn't work as well since, presumably, the recipient would also have poor reception and couldn't verify the note was actually loaded with bitcoins. Also, I REALLY don't like the name bit reserve. -Chris On 05/17/2014 11:31 AM, Jerry Felix wrote: It seems to me that there's a huge need for a paper currency that is counterfeit-resistant, inexpensive to print, internationally recognized (border-less), fits in a wallet, and machine readable. I pitched this idea at the Cincinnati Bitcoin meetup last week, and I didn't get thrown out, so I took the time to document a proposed standard to accomplish this. I've put my ideas into BIP format, so that you can see what I have in mind, although I picked some BIP numbers myself that seem to be available. Call them proposed proposals, or provisional BIPs. I've numbered them provisionally BIP-80 to BIP-84. If you guys think that this idea has some merit, let's discuss. https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki Submitted with humility and some fear of getting laughed out of here... - Jerry -- 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] ECDH in the payment protocol
Just a thought. Using the payment protocol for stealth would mean we would likely have to return to backing up wallets all the time would it not? The nonces cannot be derived from your wallet seed and, since they aren't in the blockchain, would have to be stored in your wallet. I suppose they could be stored on the server, but you would probably want a backup for that anyway. So we would end up having to back up all the time, something we're trying to get away from. Am I correct about this? On 05/09/2014 02:38 PM, Pieter Wuille wrote: On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: I don't think we're going to find that's practical unfortunately due to change. Every payment I make ties up txouts, so if we try to base the atomicity of payments on whether or not the payee decides to broadcast the transaction the payor is stuck with txouts that they can't use until the payee makes up their mind. That leads to lots and lots of nasty edge cases. I haven't talked much about it except for on IRC, but my idea was this: * PaymentACK messages become signed (with the same key as the payment request, or using some delegation mechanism, so that the same key doesn't need to remain online). * Instead of a full Bitcoin transaction, a Payment message contains a scriptSig-less Bitcoin transaction + a limit on its byte size (and perhaps a limit on its sigop count). * The sender sends such a Payment to the receiver before actually signing the transaction (or at least, before revealing the signed form). * The receiver only ACKs if the transaction satisfies the request, is within time limits, isn't unlikely to confirm. * If the sender likes the ACK (the refund and memo fields are intact, the transaction isn't changed, the signature key is valid, ...), he either sends the full transaction (with receiver taking responsibility for broadcasting) or broadcasts it himself. Together, this means that a paymentACK + a confirmed matching Bitcoin transaction can count as proof of payment. Both parties have a chance to disagree with the transaction, and are certain all communicated data (apart from transaction signatures) in both directions happened correctly before committing. It would completely remove the chance that the Bitcoin transaction gets broadcast without the receiver liking it (for legitimate or illegitimate reasons), or without the backchannel functioning correctly. It's also compatible with doing multiple payments in one Bitcoin transaction - you can ask for ACKs from multiple parties before signing the transaction. Of course, the sender can still withhold the signed transaction (in which case nothing happened, but we probably need a second timeout), or the receiver can always claim to have never received the transaction. The sender can broadcast the transaction himself in order to prevent that, after obtaining an ACK. -- 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] bits: Unit of account
Absent a concerted effort to move to something else other than 'bits', I would be willing to bet the nomenclature moves in that direction anyway. 'Bits' is just a shorten word for 'millibits' (or microbits, if you will). It's easier to say and my guess is people would tend to use it naturally own their own. Kind of like 'bucks' for dollars. The other synergies are: -bit is part of the word Bitcoin. The currency unit bit is part of a whole bitcoin. -bit symbolically represents the tech nature of the bitcoin. -bit used to be a unit of money way back when. This largely reclaims it. -when used as money bit when in references to a precession metal coin. The name 'bitcoin' references that as well as the mimicking of the gold standard in the protocol rules. All around I don't think there is a better fit. I doubt people will get confused by it. The context it's used in will distinguish it from other uses of the word. On 05/03/2014 12:27 PM, Mike Caldwell wrote: I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: 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? -- 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
Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
This scheme would discourage people from attempting a Finney attack because they would end up worse off if they did. It would work but it's an ugly hack IMO. What do people do if they don't have extra to pay when making a purchase? I have 200 mbtc and want to buy a 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me. I would much prefer the hassle of a green address notary than always having to make sure I have double what I need to make a purchase. On Apr 24, 2014 7:55 AM, Mike Hearn m...@plan99.net wrote: Am I missing something? The scheme you described does nothing about Finney attacks, which is the issue presently faced. -- 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
What is the advantage of this proposal over just orphaning the block with double spends? There's currently a set of rules which government what constitutes a valid block. Miners don't build on blocks that don't accord with those rules out of fear that a major won't follow and they will waste hashing power. If there was a rule supported by the majority that considered blocks with double spends (defined in some fashion) as invalid miners wouldn't build on them for the same reason they wouldn't build on a block with a coinbase over 25 btc, say. It seems that would accomplish the same without the other issues. On Apr 23, 2014 12:04 PM, Christophe Biocca christophe.bio...@gmail.com wrote: 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 -- 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] bits: Unit of account
You're correct, my impression of the term is based of what I experience in the US. If it is more widely used in other cultures that should be a consideration. On Apr 20, 2014 12:27 PM, Wladimir laa...@gmail.com wrote: On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia ctpa...@gmail.com wrote: The term bit is really only overloaded for those who are techy. 95% of the population never uses the term bit in their daily lives and I doubt most could even name one use of the term. Plus bit used to be a unit of money way back when, so this is kind of reclaiming it. I think it's a great fit. That's a very anglocentric way of thinking. Here in the Netherlands, a bit is something you put in a horses's mouth. It's also used as imported word (in the information sense). We've never used the term for money. Wladimir -- 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
