Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) and the fraud frequency is also much lower. 0-conf concerns were never a problem in practice. except for 2-way atms i have never heard of a problem that was caused by double spends. while adding these measures is generally positive, requiring them means excluding 99.9% of the potential users. so you might as well not do it. RBF as implemented by F2Pool just flat out lowers Bitcoins utility value. So it's a bad thing. for any online or automated system, waiting for a handful of confirmations was always recommended practice. Am 19.06.2015 um 22:39 schrieb Matt Whitlock: > Retail POS merchants probably should not be accepting vanilla Bitcoin > payments, as Bitcoin alone does not (and cannot) guarantee the > irreversibility of a transaction until it has been buried several > blocks deep in the chain. Retail merchants should be requiring a > co-signature from a mutually trusted co-signer that vows never to sign > a double-spend. 0xAA4EDEEF.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
>m/##'/0'/99'/0' > >where 99 is the identifier for, say, counterparty What is stopping you from using m/44'/9'/a'/c/i as descibed here: http://doc.satoshilabs.com/slips/slip-0044.html to avoid having an internal mapping from 9'-> 0' to find out what blockchain to query, this sounds like it should be trivial for any wallet. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
Regarding 80 bytes vs smaller: The objectives should be that if you are determined to put some extra data in the blockchain, OP_RETURN should be the superior alternative. if a user can include more data with less fees using a multisig TX, then this will happen. eventually dust-limit rules will not be the deciding factor here, since i suspect block propagation times will have a stronger effect on effective fees. therefore a slightly larger payload than the biggest multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes. (this is my understanding of how large a 3-of-3 multisig tx can be, plus 1.5 bits encoded in the "n" parameter) -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Temporary fee fix
I know we should all be brainstorming and working on a new fee market. But fact is, it will still take some time and in the meantime users will continue to shout insults at us for the high "fixed" fee of 0,1 mBtc. Even banks sometimes have less fees. (1 of 5 Play Store reviews of Mycelium seem to mention high fees recently) My suggestion: until the market is established let's lower the minimum relay fee per kb to something less. 0,01 mBtc comes to mind. (of course pulling this number out of thin air) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
> There's no reason the signing can't be done all at once. The wallet > app would create and sign three transactions, paying avg-std.D, avg, > and avg+std.D fee. It just waits to broadcast the latter two until it > has to. i see several reasons why this is problematic. So how would that work in a setting where the user signs a transaction created offline, transmitted via Bluetooth via a one-way broadcast? does it transmit all 3 tx to the receiver and just hopes they he will do the "right thing"? > > On 10/25/13 5:02 AM, Andreas Petersson wrote: >> >> >>> Worth thinking about the whole ecosystem of wallets involved; >>> they all have to handle double-spends gracefully to make tx >>> replacement of any kind user friendly. We should try to give >>> people a heads up that this is coming soon if that's your >>> thinking. >> >> If there is a situation where wallets are supposed to constantly >> monitor the tx propagation and recreate their transactions with >> different fees, this would make a lot of usecases inconvenient. >> half-offline bluetooth transactions, users with unstable >> connections, battery power lost, etc, etc. - and last but not least >> power concerns on hardware wallets on the bitcoincard (tx signing >> drains a significant amount of power and should therefore only be >> done once) >> >> -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
> Worth thinking about the whole ecosystem of wallets involved; they all > have to handle double-spends gracefully to make tx replacement of any > kind user friendly. We should try to give people a heads up that this is > coming soon if that's your thinking. If there is a situation where wallets are supposed to constantly monitor the tx propagation and recreate their transactions with different fees, this would make a lot of usecases inconvenient. half-offline bluetooth transactions, users with unstable connections, battery power lost, etc, etc. - and last but not least power concerns on hardware wallets on the bitcoincard (tx signing drains a significant amount of power and should therefore only be done once) -Andreas -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
This an excellent idea, because i proposed the same thing previously. these bip 39 mnemonics are IMO too hard to remember. using NLP we could generate a gramatically correct sentence out of 128 completely random bits which is possible to remember. information could be encoded in the selection of words but also in the choice of the syntax tree. if i had too much spare time this would be an excellent project. Am 11.09.2013 00:35, schrieb Mark Friedenbach: > For a while I've wanted to combine one of these mnemonic code generators > with an NLP engine to do something like output a short story as the > passphrase, even a humorous onem with the key encoded in the story > itself (remember the gist of the story and that's sufficient to > reconstruct the key). -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? Right now, i would simply put that into "memo" and come up with my own serialisation mechanism. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? -Andreas -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
It particulary worries me that a lot of sites hand over their SSL private keys to Cloudflare, and they are located in prism land. > Cloudflare is rapidly becoming a bitcoin community SPOF. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
my initial idea (not sure if it is good) was to have an asymetric market. lets say you want to create altcoin ALC. ALC are merge-mined with btc, though without block reward. to create 1 ALC you have two choices: destroy 1 BTC, or buy 1 ALC for a floating amount from an exchange. in my book, this would automatically lead to a slightly lower price for 1 ALC, and an automatic ceiling of 1 BTC, since you could always sacrifice BTC to gain ALC. but it would not diverge drastically lower, since apparently somebody was willing to destroy 1 BTC to create it. maybe it could even trade slightly higher because traded ALC could be spendable instantly while sacrificed ALC would need a 120 blocks maturing period. the "beauty" of that system is also it does not inflate the cryptocurrency realm. Andreas Am 14.06.2013 23:10, schrieb Luke-Jr: > Note that the "earn a mixture of BTC and TBC, but not both in full volume" > only works for TBC because the price is by definition fixed with BTC. > I'm not sure how you could implement something like this for an altcoin where > the price is floating independently of Bitcoin.. that is, how you would know > the right amount of Bitcoin to require sacrificed. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
During/before the Payment Request there should be a method to exchange the public keys to be able to generate a common multisig address. Should this be handled in a different protocol, or be included in this spec? Or is there a method for the customer to verify that the specified BIP16 Output contains his address and the one from an escrow service? -- Andreas -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
These discussed features are all useful but quite contradicting. I imagine that a user will be able to switch between different coin selection policies "minimize fees","max privacy","defragmentation","i don't care" and even switch between them for individual sends. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
I propose a pragmatic solution: Try running the Multibit client. i am not sure if the linux/java based installer would work,so maybe you have to build it from source. I tried it out is really fast compared to bitcoin-qt. after install it took me 15 seconds to get updated and running. Importing a private key/rescanning the blockchain was done in under 30 minutes. It requires Java 6, i think there is a distro even for freebsd. of course, you cannot do things as solomining with it since it uses SPV. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
Some concerns regarding Bloom Filters. I talked with Stefan Thomas on the Hackathon Berlin about this. I tried to follow the discussion closely but i have not taken a look at the code yet (is there already an implementation?) so please correct me if i got something wrong. The way the Bloom filters are planned now this requires a complicated setup. basically the client will ask the server to replay the whole blockchain, but filtered. This is not optimal for the following reasons: This will require the server to do a full scan of his data and only filter out non-matching entries. Really lightweight clients (like Bitcoincard), clients with shared private keys (electrum-style), or brainwallets - will ask the following question quite often to "supernodes": Given my public keys/addresses, what is the list of unspent outputs. i think it would make sense to include such a command, instead or in addition to the filterload/filterinit. And perhaps more severe: as far as i understand classic bloom filters, the server has no method of indexing his data for the expected requests. There is simply no data structure (or maybe it has to be invented) which allows the use of an index for queries by bloom filters of *varying length* and a generic hashing method. im not sure what a really efficient data structure for these kinds of query is. but i think it should be possible to find a good compromise between query flexibility, server load, client privacy. one possible scheme, looks like this: the client takes his list of addesses he is interested in. he hashes all of them to a fixed-length bit array (bloom filter) of length 64KiB (for example), and combines them with | to add more 1's with each address. the server maintains a binary tree data structure of unspent outputs arranged by the Bloom filter bits. to build the tree, the server would need to calculate the 64KiB bits for each address and arrange them in a binary tree. that way he can easily traverse the tree for a given bloom query. if a client whishes to query more broadly he can calculate the bloom filter to 64KiB and after that fill up the last 50% of the Bits with 1. or 95%. the trailing 1 bits even don't need to be transmitted to the server when a client is querying. of course, if the client is more privacy-concerned he could also fill up random bits with 1, which would not change much actually. the value of 64KiB is just out of thin air. according to my experimentation using BloomFilter from Guava - currently, also 8KiB would be sufficient to hava a 3% false positive rate for the 4 active addresses we have right now. someone more familiar with hashing should please give his opinion if cutting a bloom filter in half has any bad consequences. Andreas -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org - remove hackathon
Am 17.07.2012 11:17, schrieb Amir Taaki: > Like I really do not wish to sell a speaker slot, but if I have to (to pay > the bills) then it will be obvious due to scheduling and disclaimers that > speakers are sponsors. > > Personally, i really don't mind sponsored speakers. If they have somewhat relevant topics they keep the event from becoming a "circlejerk". for example i would really like to hear about payments innovation outside bitcoin. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
