Re: [Bitcoin-development] Modularizing Bitcoin
There is a modular, modern, open source implementation of the BItcoin protocol with properties, e.g. remote wallet, you look for at bitcoingrant. It is Bits of Proof. A supported and hosted product launched at the BItcoin2013. You find the source at https://github.com/bitsofproof/supernode and supporting documentation at http://bitsofproof.com Tamás Blummer -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0032
A JSON-ed version of the test vectors is here: https://github.com/bitsofproof/supernode/blob/master/api/src/test/resources/BIP32.json The Bits of Proof code matching with them is at: https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Missing fRelayTxes in version
Hi Mike, The issue with the current parser is that those fields are conditionally optional on that there will be no subsequent fields added. If there will be further fields they will become manadory. Why not bump the version and parse the fields as mandatory from then on? This would be backward compatible and cleaner going forward. Tamas Blummer http://bitsofproof.com -- 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] Missing fRelayTxes in version
I agree that this can be deferred until there is an actual new field without any harm. But then remember to update the BIP37 too saying that it is optional only if flag added in BIPXX is not present. Your argument is that this complexity is already there so why not preserve it. I think eliminating complexity (that has no benefit) strengthens the system. Tamás Blummer http://bitsofproof.com On 20.06.2013, at 09:36, Mike Hearn m...@plan99.net wrote: Sure but why not do that when there's an actual new field to add? Does anyone have a proposal for a feature that needs a new version field at the moment? There's no point changing the protocol now unless there's actually a new field to add. Anyway I still don't see why anyone cares about this issue. The Bitcoin protocol does not and never has required that all messages have a fixed number of fields per version. Any parser written on the assumption it did was just buggy. Look at how tx messages are relayed for the most obvious example of that pattern in action - it's actually the raw byte stream that's stored and relayed to ensure that fields added in new versions aren't dropped during round-tripping. Old versions are supposed to preserve fields from the future. On Thu, Jun 20, 2013 at 9:30 AM, Tamas Blummer ta...@bitsofproof.com wrote: Hi Mike, The issue with the current parser is that those fields are conditionally optional on that there will be no subsequent fields added. If there will be further fields they will become manadory. Why not bump the version and parse the fields as mandatory from then on? This would be backward compatible and cleaner going forward. Tamas Blummer http://bitsofproof.com -- 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 -- 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] Missing fRelayTxes in version
Yes it is trivial. I do not think greater complexity in the system should keep us from addressing low complexity issues. You can't blame me or others not trying to simplify scripts, if there is such a headwind simplifying a version message. You are right there is too much fuss about this. Tamás Blummer Founder, CEO http://bitsofproof.com On 20.06.2013, at 10:31, Mike Hearn m...@plan99.net wrote: You can't eliminate the complexity (yet), otherwise you wouldn't be able to talk to old nodes. You'll have to wait until versions prior to a particular version are hard-forked off and can be safely dropped at connect time. That said the reason I'm being so grumpy about this is that compared to the complexity in the rest of the system, this is such a trivial and minor detail. It's hardly even worth thinking about. I mean, we have a scripting language full of opcodes nobody ever figured out how to use and the protocol uses a mixture of byte orders, so an optional field in the version message is really not such a big deal :) On Thu, Jun 20, 2013 at 10:17 AM, Tamas Blummer ta...@bitsofproof.com wrote: I agree that this can be deferred until there is an actual new field without any harm. But then remember to update the BIP37 too saying that it is optional only if flag added in BIPXX is not present. Your argument is that this complexity is already there so why not preserve it. I think eliminating complexity (that has no benefit) strengthens the system. Tamás Blummer http://bitsofproof.com On 20.06.2013, at 09:36, Mike Hearn m...@plan99.net wrote: Sure but why not do that when there's an actual new field to add? Does anyone have a proposal for a feature that needs a new version field at the moment? There's no point changing the protocol now unless there's actually a new field to add. Anyway I still don't see why anyone cares about this issue. The Bitcoin protocol does not and never has required that all messages have a fixed number of fields per version. Any parser written on the assumption it did was just buggy. Look at how tx messages are relayed for the most obvious example of that pattern in action - it's actually the raw byte stream that's stored and relayed to ensure that fields added in new versions aren't dropped during round-tripping. Old versions are supposed to preserve fields from the future. On Thu, Jun 20, 2013 at 9:30 AM, Tamas Blummer ta...@bitsofproof.com wrote: Hi Mike, The issue with the current parser is that those fields are conditionally optional on that there will be no subsequent fields added. If there will be further fields they will become manadory. Why not bump the version and parse the fields as mandatory from then on? This would be backward compatible and cleaner going forward. Tamas Blummer http://bitsofproof.com -- 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 -- 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] SPV bitcoind? (was: Introducing BitcoinKit.framework)
Would not an SPV bitcoind transfer all control on validation rules to miner?A majority coalition of miner (pool operator) might even decide to change block rewardrules if the rest of the network only verifies POW.Regards,Tamás BlummerFounder, CEOhttp://bitsofproof.com -- 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=48808831iu=/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 (Gavin Andresen)
Since the payment request is available from a location defined in the URI,I think it would be appropriate to attach the PaymentACK once paymentaccepted by Merchant.This would make the request and receipt available for later review.Regards,Tamás BlummerFounder, CEOhttp://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/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
Two thoughts: 1. Please keep it simple, miner will override it either. 2. If block construction algorithm compares alternate chains and not individual transactions, then receiver can bump up the fee by spending the unconfirmed output again with higher fee, no need for replacement in the mempool. Tamas Blummer -- 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=60135991iu=/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
At least Trezor and bitcoinj (Multibit) seems to be going in this way, which is 100% of clients which expressed interest in bip39 :-). slush The the current spec with TREZOR's wordlist is also implemented by Bits of Proof https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/wallet/BIP39.java and deployed in two projects, one being btc1k also open sourced at our github. Regards, Tamás Blummer http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] On OP_RETURN in upcoming 0.9
It costs at least 5430 satoshis to create an output at the moment. Is the same spam limit applied if the script is OP_RETURN? If not, I would be concerned od opening a cheap spam. Tamas Blummer On Mon, Feb 24, 2014 at 11:39 AM, Wladimir laa...@gmail.com wrote: And if this is not abused, these kind of transactions become popular, and more space is really needed, the limit can always be increased in a future version. Wladimir signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
Jeff's arguments are understood and supported by those who worked in finance. Existing financial applications have often problems dealing with more than 2 decimals. People who work in finance are used to two decimals. Neither systems nor people in finance have a problem with large numbers though. For above practical reasons I am also for moving to a unit that equals 100 satoshi. I heard the name bit for it which I like. Regards, Tamás Blummer Founder, CEO Bits of Proof http://bitsofproof.com -- 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/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 13.03.2014, at 17:14, Alan Reiner etothe...@gmail.com wrote: We've been working with Marty Zigman who's creating a Bitcoin plugin for NetSuite accounting platform, and he was already forced to switch micro-BTC long ago for exactly the reasons described above. I think the system will track up to 3 decimal places without causing all sorts of heartache and automatic rounding. Of course, as Mike said, this ship may have already sailed, but if there's any way to revisit this, I'm there. We're just about to do another Armory release and could support this very easily. Not suprised that people dealing with real world finance problems and people who are not engineers come to the same conclusion. Welcome Alan! Why not add 'bit' as an option or even default to Armory? Regards, Tamas Blummer Founder, CEO Bits of Proof http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- 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/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
BTW, its not like this would be the first time this was raised, instead the ship left while ignoring arguments. The idea of is up there for votes since March 2013 https://bitcointalk.org/index.php?topic=149150.0 and received the most votes. I remembered this last time on this list here: http://sourceforge.net/p/bitcoin/mailman/message/31640769/ Regards, Tamas Blummer Founder, CEO Bits of Proof http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- 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/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach andr...@schildbach.de wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon screenshot: http://imgur.com/a/WCDoG Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html On 13 March 2014 12:56, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. On Sun, Nov 17, 2013 at 9:28 PM, Wendell w...@grabhive.com mailto:w...@grabhive.com wrote: We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved. -wendell grabhive.com http://grabhive.com | twitter.com/hivewallet http://twitter.com/hivewallet | gpg: 6C0C9411 On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote: Go straight to uBTC. Humans and existing computer systems handle numbers to the left of the decimals just fine (HK Dollars, Yen). The opposite is untrue (QuickBooks really does not like 3+ decimal places). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto: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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases
Re: [Bitcoin-development] moving the default display to mbtc
you miss the point Andreas. It is not about the magnitude but about the form of a price. A number with no decimals or with two decimals is percieved as a price in some currency. A number with more than two decimals is just not percieved as a price but as a geeky something that you rather convert to local currency. Tamas Blummer Bits of Proof On 14.03.2014, at 15:49, Andreas Schildbach andr...@schildbach.de wrote: How much do you pay for an Espresso in your local currency? At least for the Euro and the Dollar, mBTC 3.56 is very close to what people would expect. Certainly more familiar than µBTC 3558 or BTC 0.003578. Anyway, I was just sharing real-world experience: nobody is confused. On 03/14/2014 03:14 PM, Tamas Blummer wrote: You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach andr...@schildbach.de wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon screenshot: http://imgur.com/a/WCDoG Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html On 13 March 2014 12:56, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. On Sun, Nov 17, 2013 at 9:28 PM, Wendell w...@grabhive.com mailto:w...@grabhive.com wrote: We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved. -wendell grabhive.com http://grabhive.com | twitter.com/hivewallet http://twitter.com/hivewallet | gpg: 6C0C9411 On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote: Go straight to uBTC. Humans and existing computer systems handle numbers to the left of the decimals just fine (HK Dollars, Yen). The opposite is untrue (QuickBooks really does not like 3+ decimal places). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto: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
Re: [Bitcoin-development] moving the default display to mbtc
I think you want to misunderstand me Andreas. It is astonishing arrogance to define the units because we in Bitcoin are used to some wierd notation and ignore that the vast majority of population and financial software in existence does not have a notion of prices with more than two decimals. With 1 bit = 100 satoshi, we would solve this problem for good. Instead mBTC is a confusing step in-between. Tamas Blummer http://bitsofproof.com On 14.03.2014, at 16:02, Andreas Schildbach andr...@schildbach.de wrote: By that definition 3.56 is a price. Maybe I misunderstood you and you're lobbying for mBTC? On 03/14/2014 03:57 PM, Tamas Blummer wrote: you miss the point Andreas. It is not about the magnitude but about the form of a price. A number with no decimals or with two decimals is percieved as a price in some currency. A number with more than two decimals is just not percieved as a price but as a geeky something that you rather convert to local currency. Tamas Blummer Bits of Proof On 14.03.2014, at 15:49, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: How much do you pay for an Espresso in your local currency? At least for the Euro and the Dollar, mBTC 3.56 is very close to what people would expect. Certainly more familiar than µBTC 3558 or BTC 0.003578. Anyway, I was just sharing real-world experience: nobody is confused. On 03/14/2014 03:14 PM, Tamas Blummer wrote: You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for leading/trailing symbol, commas, spaces and points. This allows anyone to customise to meet their own needs beyond the offered default. We apply the NIST guidelines for representation of SI unit symbols (i.e no conversion to native language, no RTL giving icon+m etc). Right now MultiBit HD is configured to use m+icon taken from the Font Awesome icon set. However reading earlier posts it seems that μ+icon is more sensible. Let us know what you'd like. Links: m+icon screenshot: http://imgur.com/a/WCDoG Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html On 13 March 2014 12:56, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. -- 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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide
Re: [Bitcoin-development] New BIP32 structure
We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof) at the Inside Bitcoin Conference in Berlin. I remember that there were different opinions on how to use a hierarchy and it did seem to me they could eventually be standardized for the retail customer but definitelly not for corporate use, where hierarchy will certainly map to organisational hierarchy or cost centres. A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word Bitcoin, Litecoin, Dogecoin, so collosion is unlikely and cetral directory is not needed. Regards, Tamas Blummer http://bitsofproof.com On 26.03.2014, at 21:49, Mike Hearn m...@plan99.net wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: cointype: This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the raw money and it will just ignore/not see the keys used in more complex transactions. reserved is for other stuff. I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas? account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that. change is 0 for receiving addresses, 1 for change addresses. n is the actual key index For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible. The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support. Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
I think not all alts (will) have magic numbers, at least not those defined e.g. with colored coins on top of an other chain. Also note that the index should have MSB cleared as it would otherwise indicate private derivation. Regards, Tamas Blummer http://bitsofproof.com On 27.03.2014, at 16:57, Allen Piscitello allen.piscite...@gmail.com wrote: Don't most of these coins have a magic number already assigned that is unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for Litecoin, etc...). This seems like a good candidate for identifying coins, and also supports Testnet cases well. Maybe there are some alts without such a magic number that might prevent that? -Allen On Thu, Mar 27, 2014 at 10:43 AM, Jeff Garzik jgar...@bitpay.com wrote: On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer ta...@bitsofproof.com wrote: A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word Bitcoin, Litecoin, Dogecoin, so collosion is unlikely and cetral directory is not needed. +1 good idea -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
Yes, you begin to see that the payment protocol, as is has a too narrow scope of a web cart - customer, and does not even fit that. It is not about payment requests but about business relationships. We need a protocol that deals with that concept instead of individual requests, so we really get out of the hell of addresses. Business relationships are terminated by the parties at their own and not bey algorithms and timeouts. Regards, Tamas Blummer http://bitsofproof.com On 28.03.2014, at 12:38, Wladimir laa...@gmail.com wrote: On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@schildbach.de wrote: I see the problem. However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the time of the initial payment). You're probably aiming for an expires field? How would you refund a payment after expiry? Note its not your choice wether to refund a payment -- it can be ordered by a court years after the payment happened. Communication between the merchant and buyer would be needed in this case. I'd say that would be not unreasonable if something is to be refunded after a year or more. After all, people may have moved, bank accounts changed, even outside the bitcoin world. It should probably not be accepted to set a very low expiration time for the refund address, like 3 months, as it's as bad as not providing a refund address at all and brings back all the pre-BIP70 confusion. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 12:46, Mike Hearn m...@plan99.net wrote: I don't want to manage a business relationship with every shop I buy something from. That's way too much effort. There can certainly be cases where a more complicated relationship is created by bootstrapping off BIP70, perhaps with an extension, but nailing the ordinary buyer-to-seller relationship seems like a good scope for BIP70 for now. It is not more effort than an auto remembered call-in phone number. You delete if you do not care. The difference however is that it would be a clean protocol for repeated payments in both directions for whatever reason, where refund is and payment are not special compared to 1st installment, overpayed back or tip or whatever extra charge arises later. On Fri, Mar 28, 2014 at 12:45 PM, Tamas Blummer ta...@bitsofproof.com wrote: Yes, you begin to see that the payment protocol, as is has a too narrow scope of a web cart - customer, and does not even fit that. It is not about payment requests but about business relationships. We need a protocol that deals with that concept instead of individual requests, so we really get out of the hell of addresses. Business relationships are terminated by the parties at their own and not bey algorithms and timeouts. Regards, Tamas Blummer http://bitsofproof.com istinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 14:00, Mike Hearn m...@plan99.net wrote: What is too abstract in a contact list ? If the payment comes with a tag like refund the UI could display as such and if it comes with e.g. VAT then that. How is this any different? The tag in this case is the address and the payment is being delivered by the block chain (direct submission for user-merchant is easier than merchant-user) so we can't stuff extra data anywhere else. Then the UI knows it was a refund payment and not for anything else. The difference is the concept of setting up a channel that allows both parties to create valid addresses of the other by exchanging some kind of master keys. The initial handshake with the protocol would agree on tags of individual address indexes if used. The wallets would have to observe those agreed inidices and evtl. extend range. Payments could go back and forth. Either party might delete the channel information and stop observing keys as soon as he does no longer expect a payment from the other. This would be an explicit operation, like deleting a contact. I don't see the relevance of VAT here. It was an example label. I would not be suprised if with widespread use of payments some government would require VAT collected separately. It is just a guess and has no weight in my prior arguments. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 13:27, Mike Hearn m...@plan99.net wrote: It is not more effort than an auto remembered call-in phone number. You delete if you do not care. The difference however is that it would be a clean protocol for repeated payments in both directions for whatever reason, where refund is and payment are not special compared to 1st installment, overpayed back or tip or whatever extra charge arises later. I think that'd be too abstract. The purpose of the refund field is that so if/when you receive a payment there, the wallet UI can do something intelligent, like show you in your transactions list that a certain payment was refunded using language the user will understand. If it's modelled at the protocol level without that then it makes producing good UI's harder. What is too abstract in a contact list ? If the payment comes with a tag like refund the UI could display as such and if it comes with e.g. VAT then that. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 16:23, Mike Hearn m...@plan99.net wrote: So I take it BOPShop won't be supporting BIP70 then? :( Supporting BIP70 by BitPay or BopShop is a cake since it does no more then they did without it. I am not in opposition but see no reason to be enthusiastic about it. I will once the spec goes further than what was possible before. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 17:34, Mike Hearn m...@plan99.net wrote: Supporting BIP70 by BitPay or BopShop is a cake since it does no more then they did without it. I am not in opposition but see no reason to be enthusiastic about it. I will once the spec goes further than what was possible before. So, if e.g. Trezor ships a firmware update that uses BIP70 to present signed payment identities on the screen, would you support it then? Yes that would be neat and I would not want to spoil the show. I wish the established identity could be re-used though to send and much more. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
May I ask how the current payment protocol is supposed to handle salaries? I hope you do not assume the employee creates a payment request, since he does not even calculate the amount. There you go where a channel I described is definitelly needed. Tamas Blummer http://bitsofproof.com On 28.03.2014, at 12:30, Tamas Blummer ta...@bitsofproof.com wrote: Instead of a payment request and refund, businesses would actually need a payment channel, that once established allows for multiple payments back and forth between counterparties. One might have a number of open channels until the business relationship is assumed. The customer might decide to close the channel explicitelly once he does no longer expect a payment. Regards, Tamás Blummer http://bitsofproof.com On 28.03.2014, at 12:07, Mike Hearn m...@plan99.net wrote: Modern devices like smartphones and tablets do not have swap files. This design is chosen to ensure responsive, fluid UI that can avoid blocking on disk regardless of how much multi-tasking is done, but it creates ripples that impact everything else. One implication of this is that on these devices, we cannot store all keys or transactions in memory forever. BIP 70 has an expiry field for PaymentRequests that we can use to allow us to eventually stop loading those keys into RAM - at that point payments to those keys would no longer be recognised. But there's no equivalent for refund addresses. More generally, though we re-used the output structure to define the refund, we didn't (for some reason that I forgot) reuse PaymentDetails, even though the payment details for a refund are indeed PaymentDetails. Though I am loathe to go back and redesign this part of BIP 70 so soon after we shipped v1, it seems to me like the refund feature may be hard to implement on phones if there's no time limit for when you can receive a refund. Otherwise a wallet has to be looking out for refunds for payments you may have made years ago. So perhaps we should add a new refund field that embeds a PaymentDetails structure instead of being just a list of outputs. We could try and solve this problem some other way purely internally, by doing a kind of wallet-specific swapping process in which things like Bloom filters are calculated without all keys in them being held in memory at once (perhaps caching filters for old parts of the key chain on disk), so you can have infinite wallets, but eventually the huge Bloom filters that would result would hurt efficiency in other ways. So key expiry seems pretty fundamental to scalability. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
I have nothing against incremental development. This will however not pick up until it offers some incremental benefit compared to current payment processor solutions, such as e.g. 1. Symmetrical. One can also offer a payment. 2. Aggregating and Netting. Handle multiple installments and/or net with previous cash flows. 3. More secure. One has a check not only on the payment address (which already has one with https:// in the web shop scenario it is currently able support) but not on the refund. On 28.03.2014, at 15:01, Gavin Andresen gavinandre...@gmail.com wrote: On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@bitsofproof.com wrote: May I ask how the current payment protocol is supposed to handle salaries? It doesn't. walk before you run and all that; lets see what problems we run into with the minimal payment protocol we have now (like refund outputs you have to remember forever) before we create an insurmountable set of problems by trying to solve everything we can think of all at once. -- -- Gavin Andresen signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Great stuff Matt! I have an implementation of Shamir's Secret Sharing here: https://github.com/bitsofproof/bop-bitcoin-client-misc/blob/master/src/main/java/com/bitsofproof/supernode/misc/ShamirsSecretSharing.java What was missing was nice serialization. Thanks a lot for defining and starting the process. I will shortly adapt my code and check your test vectors. Regards, Tamas Blummer http://bitsofproof.com On 29.03.2014, at 09:05, Matt Whitlock b...@mattwhitlock.name wrote: Abstract: A method is described for dividing a Bitcoin private key into shares in a manner such that the key can be reconstituted from any sufficiently large subset of the shares but such that individually the shares do not reveal any information about the key. This method is commonly known as Shamir's Secret Sharing Scheme. Additionally, an encoding methodology is proposed to standardize transmission and storage of shares. Complete BIP: https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki I am looking to have this BIP assigned a number and added to the bitcoin/bips repository. I invite any comments, questions, or suggestions. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Hi Matt, I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key. Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed. Regards, Tamas Blummer http://bitsofproof.com On 29.03.2014, at 09:05, Matt Whitlock b...@mattwhitlock.name wrote: Abstract: A method is described for dividing a Bitcoin private key into shares in a manner such that the key can be reconstituted from any sufficiently large subset of the shares but such that individually the shares do not reveal any information about the key. This method is commonly known as Shamir's Secret Sharing Scheme. Additionally, an encoding methodology is proposed to standardize transmission and storage of shares. Complete BIP: https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki I am looking to have this BIP assigned a number and added to the bitcoin/bips repository. I invite any comments, questions, or suggestions. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
I had Matt's answer already, see below, but then I recognized that the group was not cc:-d, so I repeat: It would help on the user interface to include into individual shares: 1. Number of shares needed 2. A few bytes fingerprint of the secret so shares that likely belong together can be identified. I wonder how others weight security vs. usability in these questions. Regards, Tamas Blummer http://bitsofproof.com On Saturday, 29 March 2014, at 6:22 pm, Tamas Blummer wrote: It might make sense to store the number of shares needed. I know it is not needed by math, but could help on user interface to say, you need x more shares.. I intentionally omitted that information because it's a security risk. If an adversary gains control of one share and can see exactly how many more shares he needs, he may be able to plan a better attack. If he is clueless about how many shares he needs, then he may not be able to execute an attack at all because he may not know whether his information about what shares exist and where is complete. On 29.03.2014, at 17:54, Matt Whitlock b...@mattwhitlock.name wrote: On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote: I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key. Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed. I have expanded the BIP so that it additionally applies to BIP32 master seeds of sizes 128, 256, and 512 bits. https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki The most significant change versus the previous version is how the coefficients of the polynomials are constructed. Previously they were SHA-256 digests. Now they are SHA-512 digests, modulo a prime number that is selected depending on the size of the secret. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
On 29.03.2014, at 18:46, Gregory Maxwell gmaxw...@gmail.com wrote: In this case I don't see anything wrong with specifying secret sharing, but I think— if possible— it should be carefully constructed so that the same polynomials and interpolation code can be used for threshold signatures (when encoding compatible data). The paper http://www.cs.princeton.edu/~stevenag/bitcoin_threshold_signatures.pdf does not mention anything special about the polynomial to use other than: random polynomial f of degree t - 1 such that d = f(0) Do you have reasons to assume that there is more to this? Since this is compatible with Matt's proposal. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
I rather prefer to start with SPV and upgrade to full node, if desired. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 19:40, Mike Hearn m...@plan99.net wrote: Actually, I wonder if we should start shipping (auditable) pre-baked databases calculated up to the last checkpoint so people can download them and boot up their node right away. Recalculating the entire thing from scratch every time isn't sustainable in the long run anyway. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Headers first loading allows the node to run SPV from the very first minutes and it can converge to full node by time. This is BTW how newest versions of BOP can work. Pruning however disqualifies the node as a source for bootstrapping an other full node. BTW, did we already agree on the service bits for an archive node? Tamas Blummer http://bitsofproof.com On 07.04.2014, at 20:23, Mike Hearn m...@plan99.net wrote: * Sent 456.5 gb data At my geographic service location (Singapore), this cost about $90 last month for bandwidth alone. One of the reasons I initiated the (now stalled) PayFile project was in anticipation of this problem: https://github.com/mikehearn/PayFile http://www.youtube.com/watch?v=r0BXnWlnIi4feature=youtu.be At some point if you want to actually download and validate the full block chain from scratch, you will have to start paying for it I'm sure. In the meantime: Getting headers-first implemented and rolled out everywhere would reduce the amount of redundant downloading and hopefully reduce transmit traffic network-wide. Implementing chain pruning would allow people to control upload bandwidth consumption by reducing the amount of disk storage they allow. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes. Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node, therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 20:49, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer ta...@bitsofproof.com wrote: BTW, did we already agree on the service bits for an archive node? I'm still very concerned that a binary archive bit will cause extreme load hot-spotting and the kind of binary Use lots of resources YES or NO I think we're currently suffering some from, but at that point enshrined in the protocol. It would be much better to extend the addr messages so that nodes can indicate a range or two of blocks that they're serving, so that all nodes can contribute fractionally according to their means. E.g. if you want to offer up 8 GB of distributed storage and contribute to the availability of the blockchain, without having to swollow the whole 20, 30, 40 ... gigabyte pill. Already we need that kind of distributed storage for the most recent blocks to prevent extreme bandwidth load on archives, so extending it to arbitrary ranges is only more complicated because there is currently no room to signal it. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Maybe it is not a question of the maturity of the implementation but that of the person making presumptions of it. I consider a fully pruned blockchain being equivalent to the UTXO. Block that hold no more unspent transaction are reduced to a header. There is however no harm if more retained. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:02, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer ta...@bitsofproof.com wrote: Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes. Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node, therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges. This isn't at all how pruning works in Bitcoin-QT (nor is it how I expect pruning to work for any mature implementation). Pruning can work happily on a whole block at a time basis regardless if all the transactions in it are spent or not. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Once headers are loaded first there is no reason for sequential loading. Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:03, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer ta...@bitsofproof.com wrote: therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges. A bitmap also means high overhead and— if it's used to advertise non-contiguous blocks— poor locality, since blocks are fetched sequentially. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
You have the trunk defined by the headers. Once a range from genesis to block n is fully downloaded, you may validate upto block n. Furthermore after validation you can prune transactions spent until block n. You would approach the highest block with validation and stop pruning say 100 blocks before it, to leave room for reorgs. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:13, Mark Friedenbach m...@monetize.io wrote: On 04/07/2014 12:20 PM, Tamas Blummer wrote: Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. And how do you find those blocks? I have a suggestion: have nodes advertise which range of full blocks they possess, then you can perform synchronization from the adversed ranges! -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
You have to load headers sequantially to be able to connect them and determine the longest chain. Blocks can be loaded in random order once you have their order given by the headers. Computing the UTXO however will force you to at least temporarily store the blocks unless you have plenty of RAM. Regards, Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:30, Paul Lyon pml...@hotmail.ca wrote: I hope I'm not thread-jacking here, apologies if so, but that's the approach I've taken with the node I'm working on. Headers can be downloaded and stored in any order, it'll make sense of what the winning chain is. Blocks don't need to be downloaded in any particular order and they don't need to be saved to disk, the UTXO is fully self-contained. That way the concern of storing blocks for seeding (or not) is wholly separated from syncing the UTXO. This allows me to do the initial blockchain sync in ~6 hours when I use my SSD. I only need enough disk space to store the UTXO, and then whatever amount of block data the user would want to store for the health of the network. This project is a bitcoin learning exercise for me, so I can only hope I don't have any critical design flaws in there. :) From: ta...@bitsofproof.com Date: Mon, 7 Apr 2014 21:20:31 +0200 To: gmaxw...@gmail.com CC: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Why are we bleeding nodes? Once headers are loaded first there is no reason for sequential loading. Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:03, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer ta...@bitsofproof.com wrote: therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges. A bitmap also means high overhead and— if it's used to advertise non-contiguous blocks— poor locality, since blocks are fetched sequentially. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Specialization of nodes is ongoing most prominent with SPV wallets and mining. There is a need I see on my own business for software that is able to serve multiple wallets, and is multi tiered, so the world facing P2P node can be in a DMZ. I target them with a hybrid model that is SPV plus mempool transaction validation against UTXO and use ‘reference’ implementations as border router. I think that this setup will be common for enterprises and hence push for a stripped down ‘reference’ border router without wallet, payment protocol, GUI, RPC calls here. That border router could also serve as archive node evtl. also offering blocks at bulk e.g. through http. Enterprises that run a multi tiered environment have the bandwith to serve as archives. Tamas Blummer http://bitsofproof.com On 08.04.2014, at 05:44, Jeff Garzik jgar...@bitpay.com wrote: Being Mr. Torrent, I've held open the 80% serious suggestion to simply refuse to serve blocks older than X (3 months?). That forces download by other means (presumably torrent). I do not feel it is productive for any nodes on the network to waste time/bandwidth/etc. serving static, ancient data. There remain, of course, issues of older nodes and getting the word out that prevents this switch from being flipped on tomorrow. On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer ta...@bitsofproof.com wrote: BTW, did we already agree on the service bits for an archive node? I'm still very concerned that a binary archive bit will cause extreme load hot-spotting and the kind of binary Use lots of resources YES or NO I think we're currently suffering some from, but at that point enshrined in the protocol. It would be much better to extend the addr messages so that nodes can indicate a range or two of blocks that they're serving, so that all nodes can contribute fractionally according to their means. E.g. if you want to offer up 8 GB of distributed storage and contribute to the availability of the blockchain, without having to swollow the whole 20, 30, 40 ... gigabyte pill. Already we need that kind of distributed storage for the most recent blocks to prevent extreme bandwidth load on archives, so extending it to arbitrary ranges is only more complicated because there is currently no room to signal it. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Pieter, your suggestion has charm since “Bitcoin seed” would even not need a global dictionary like the interpretation of the first level, since it would be self describing. Regards, Tamas Blummer http://bitsofproof.com On 08.04.2014, at 15:53, Pieter Wuille pieter.wui...@gmail.com wrote: I see the cause of our disagreement now. You actually want to share a single BIP32 tree across different currency types, but do it in a way that guarantees that they never use the same keys. I would have expected that different chains would use independent chains, and have serializations encode which chain they belong to. Let me offer an alternative suggestion, which is compatible with the original default BIP32 structure: * You can use one seed across different chains, but the master nodes are separate. * To derive the master node from the seed, the key string Bitcoin seed is replaced by something chain-specific. * Every encoded node (including master nodes) has a chain-specific serialization magic. This is in practice almost the same as your suggestion, except that the m/cointype' in m/cointype'/account'/change/n is replaced by different masters. The only disadvantage I see is that you do not have a way to encode the super master that is the parent of all chain-specific masters. You can - and with the same security properties - encode the seed, though. -- Pieter On Tue, Apr 8, 2014 at 3:43 PM, slush sl...@centrum.cz wrote: tl;dr; It is dangerous to expect that other seed than xprv does not contain bitcoins or that xprv contains only bitcoins, because technically are both situations possible. It is still safer to do the lookup; the magic itself is ambiguous. Marek On Tue, Apr 8, 2014 at 3:40 PM, slush sl...@centrum.cz wrote: Serialization magic of bip32 seed is in my opinion completely unnecessary. Most of software does not care about it anyway; You can use xprv/xpub pair for main net, testnet, litecoin, dogecoin, whatevercoin. Instead using the same seed (xprv) and then separate the chains *inside* the bip32 path seems more useful to me. Marek -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
YES Such a bitcoind is what I called border router in a previous mail. Yes, SPV wallets are getting ahead of features, so people will use them also because on size just does not fit all, but all want to ensure being on the same trunk of the chain. Therefore serious user of Bitcoin run a bitcoind as a border router and connect SPV wallets with higher functionality to that trusted node(s). This is what I think the core should focus on: Being a lightweight superfast consensus building border router and nothing more. No wallet, no GUI, no RPC calls, no Payment protocol and the rest. Regards, Tamas Blummer http://bitsofproof.com On 09.04.2014, at 17:29, Wladimir laa...@gmail.com wrote: Hello, This is primarily aimed at developers of SPV wallets. The recently reported decrease in number of full nodes could have several reasons, one of them that less people are running Bitcoin Core for the wallet because the other wallets are getting ahead in both features and useability. It's great to see innovation in wallets, but it's worrying that the number of full nodes decreases. It may be that lots of people would support the network by running a full node, but don't want to go through the trouble of installing bitcoin core separately (and get confused because it's a wallet, too). Hence I'd like to explore the idea of adding an option to popular SPV wallets, to spin a bitcoind process in the background. This could be pretty much transparent to the user - it would sync in the background, the wallet could show statistics about the node, but is not dependent on it. In exchange the user would get increased (full node level) security, as the SPV wallet would have a local trusted node. Does this sound like a good idea? Is there any way that Bitcoin Core can help to accomedate this 'embedded' usage? Specific Interfaces, special builds - maybe add a walletless bitcoind build to gitian - bindings, dlls, etc? Wladimir -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
I am glad that SPV wallets are discussed outside the scope of mobile devices! Yes, SPV is a sufficient API to a trusted node to build sophisticated features not offered by the core. SPV clients of the border router will build their own archive and indices based on their interest of the chain therefore the border router core does not need to store (and process) anything not needed for consensus, its memory or disk footprint would be as low as an optimal storage of UTXO. Regards, Tamás Blummer http://bitsofproof.com On 09.04.2014, at 17:57, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Apr 9, 2014 at 8:42 AM, Brian Hoffman brianchoff...@gmail.com wrote: How would this affect the user in terms of disk storage? They're going to get hammered on space constraints aren't they? If it's not required how likely are users to enable this? If Bitcoin core activates pruning a full node can be supported in— say— 4GBytes or so. (That gives enough space to store the utxo about 350MB now, and a couple gigs for blocks to serve out). I'd imagine getting information from SPV wallet developers how much disk usage agility they think is required is part of what Wladimir is looking for. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Block header has to be available in SPV and also in an UTXO only storing core node, so why not serve it if bandwith allows. Serving any additional information like known peer adresses or known full blocks is certainly beneficial and should be offered if at hand. Regards, Tamas Blummer http://bitsofproof.com On 09.04.2014, at 19:46, Peter Todd p...@petertodd.org wrote: Signed PGP part On 9 April 2014 12:27:13 GMT-04:00, Tamas Blummer ta...@bitsofproof.com wrote: A border router that is not able to serve blocks is still protecting consensus rules, that SPVs do not. If the network would only consist of SPV nodes only then e.g. a majority coalition of miner could increase their reward at will. Archives need a different solution. Any collective group that has a majority of hashing power will have no major issues running enough nodes that follow their rules to make SPV insecure anyway. There's no good reason not to have SPV security nodes distribute block chain data, particularly block headers. It helps provide redundancy in the network topology and helps provide more resources for full nodes to sync up faster. For instance in a network with a large number of partial UTXO set nodes if those nodes are forwarding block data to each other they can get enough data to become fully fledged full nodes without putting all the load on the existing full nodes. This is a good thing. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Hi Wladimir, If the motivation of the SPV wallet is to radically extend functionality, as in my case, then the index is specific to the added features and the subset of the blockchain that is of interest for the wallet. As you also point out, adding huge generic purpose indices to core would rather discourage people using full nodes due to excess requirements. I believe nothing would add more to the core’s popularity as a trusted background node to SPV than full validation at lowest possible memory, disk and CPU footprint. Serving headers should be default but storing and serving full blocks configurable to ranges, so people can tailor to their bandwith and space available. Tamas Blummer Bits of Proof On 09.04.2014, at 21:25, Wladimir laa...@gmail.com wrote: Adding a RPC call for a address - utxo query wouldn't be a big deal. It has been requested before for other purposes as well, all the better if it helps for interaction with Electrum. Spent history would be involve a much larger index, and it's not likely that will end up in bitcoin Wladimir signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
You ask why people would install this ? I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network. What about serving archive blocks to peers paying for it ? Tamas Blummer http://bitsofproof.com On 10.04.2014, at 08:50, Wladimir laa...@gmail.com wrote: The only drawback would be that initially, people wouldn't know why or when to install this, hence my suggestion to pack it with wallets... Wladimir signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
I know the idea is not new. Just bringing it up to emphasize that if we don’t use it how could we expect other networks using it. Machine to machine micro payments could become the killer application for Bitcoin. 1) There is no catch 22 as there are plenty of ways getting bitcoin without bootstrapping a full node. 2) let markets work out and not speculate what would happen. 3) Serving archive bolcks does not have to be part of core but could be a distinct service written in a language of your choice using new protocol. As mentioned earlier I am for a stripped down core that does nothing else than consensus and stores nothing else needed for that task and offering SPV api to the wallets. Tamas Blummer http://bitsofproof.com On 10.04.2014, at 11:17, Mike Hearn m...@plan99.net wrote: I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network. It's not a new idea, obviously, but there are some practical consequences: 1) To pay a node for serving, you have to have bitcoins. To get bitcoins, you need to sync with the network via a node. Catch 22. 2) If some nodes choose to charge and others choose to not charge, a smart wallet will always use the free nodes. In the absence of any global load balancing algorithms, this would lead to the free nodes getting overloaded and collapsing whilst the for-pay nodes remain silent. 3) The only payment channel implementations today are bitcoinj's (Java) and one written by Jeff in Javascript. There are no C++ implementations. And as Matt and I can attest to, doing a real, solid, fully debugged implementation that's integrated into a real app is a lot of work. I still think the lowest hanging fruit is basic, boring optimisations rather than architectural rethinks. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Thanks, Peter and you convinced me. I run away with a thought. It’d be great to find a spot to deploy payment channels, but I agree this is not it. Tamas Blummer http://bitsofproof.com On 10.04.2014, at 12:40, Mike Hearn m...@plan99.net wrote: 1) There is no catch 22 as there are plenty of ways getting bitcoin without bootstrapping a full node. I think I maybe wasn't clear. To spend coins you need transaction data. Today, the dominant model is that people get that data by scanning the block chain. If you can obtain the transaction data without doing that then, either: 1) Someone is doing chain scanning for free. See my point about why pay if you can get it for free. 2) You got your tx data direct from the person you who sent you the funds, perhaps via the payment protocol. This would resolve the catch 22 by allowing you to spend bitcoins without actually having talked to the P2P network first, but we're a loong way from this world. And that's it. I don't think there are any other ways to get the tx data you need. Either someone gives it to you in the act of spending, or someone else gives it away for free, undermining the charge-for-the-p2p-network model. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
Here is an earlier reference to bits: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html I forgot that Alan Reiner was also supporting a unit equals to bits : https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html and here the earlier going back to March 2013 and a poll at that time pushing for XBT being 1 bit https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html Regards, Tamas Blummer http://bitsofproof.com On 20.04.2014, at 16:53, Pieter Wuille pieter.wui...@gmail.com wrote: I told him specifically to bring it here (on a pull request for Bitcoin Core), as there is no point in making such convention changes to just one client. I wasn't aware of any discussion about the bits proposal here before. On Sun, Apr 20, 2014 at 4:28 PM, 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
I think we have two very good candidates both substantiated with arguments for their use in their context: bit - the word for everyday use XBT - the acronym to fit into the ISO currency set. both meaning 100 satoshis or 1e-6 Bitcoin. I am glad that I erred, and this list finaly cares of finance customs and average Joe’s. Regards, Tamas Blummer http://bitsofproof.com On 21.04.2014, at 07:41, Pieter Wuille pieter.wui...@gmail.com wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com wrote: Something tells me this would be reduced to a single syllable in common usage I.e. bit. What units will be called colloquially is not something developers will determine. It will vary, depend on language and culture, and is not relevant to this discussion in my opinion. It may well be that people in some geographic or language area will end up (or for a while) calling 1e-06 BTC bits. That's fine, but using that as official name in software would be very strange and potentially confusing in my opinion. As mentioned by others, that would seem to me like calling dollars bucks in bank software. Nobody seems to have a problem with having colloquial names, but US dollar or euro are far less ambiguous than bit. I think we need a more distinctive name. -- Pieter -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Here is one to please those looking for a “fully qualified” slang word, that links with the official XBT: xbit (spoken: ex-bit) would rationalise XBT (where X comes from supranational use) and is unique. I personally associate from x to six also supporting the 1e-6 divisor of Bitcoin. Regarding XBT: No matter who used it for what. The way Bloomberg will use it will define its use in finance, and since that did not happen yet, we are not late to shape. Regards, Tamas Blummer http://bitsofproof.com On 21.04.2014, at 07:41, Pieter Wuille pieter.wui...@gmail.com wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com wrote: Something tells me this would be reduced to a single syllable in common usage I.e. bit. What units will be called colloquially is not something developers will determine. It will vary, depend on language and culture, and is not relevant to this discussion in my opinion. It may well be that people in some geographic or language area will end up (or for a while) calling 1e-06 BTC bits. That's fine, but using that as official name in software would be very strange and potentially confusing in my opinion. As mentioned by others, that would seem to me like calling dollars bucks in bank software. Nobody seems to have a problem with having colloquial names, but US dollar or euro are far less ambiguous than bit. I think we need a more distinctive name. -- Pieter -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Thomas V: Your proposal misses the points that: - this is about a unit with 1e-6 Bitcoins or 100 satoshis. - it is not about people who know Bitcoin and are techies, but about those who don’t and aren’t. The reasons for such a unit are more than shifting the comma some places for convinience, but to align Bitcoin with capabilities of existing financial software and customs of finance and average people, and ISO standard of currency abbreviations. bit and XBT seems to check the boxes. I would love to have some feedback on xbit as per my previous mail. Regards, Tamas Blummer http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
xbit is close to XBT because it would be the same unit, both would mean 100 satoshi or 1e-6 Bitcoin. xbit would be for everyday use, XBT for ISO. I know, the XBT was used by some sites to be a synonym for BTC that is however in my opinion not yet graved in stone until it is used by e.g. Bloomberg. Regards, Tamas Blummer http://bitsofproof.com On 21.04.2014, at 14:14, Un Ix slashdevn...@hotmail.com wrote: Tamas, xbit is only a typo or spelling error away from XBT, and some folks may assume they refer to the same unit of measure, not knowing the new currency system as developers here do. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Extra encoding for testnet is quite useless complexity in face of many alt chains. BIPS should be chain agnostic. Regards, Tamas Blummer http://bitsofproof.com On 22.04.2014, at 10:35, Matt Whitlock b...@mattwhitlock.name wrote: On Tuesday, 22 April 2014, at 4:11 am, Matt Whitlock wrote: On Tuesday, 22 April 2014, at 10:06 am, Jan Møller wrote: - I think it is very useful to define different prefixes for testnet keys/seeds. As a developer I use the testnet every day, and many of our users use it for trying out new functionality. Mixing up keys meant for testnet and mainnet is bad. A fair point. I'll add some prefixes for testnet. Testnet encodings are added: https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
I do not suggest to encode the chain, in contrary. I consider the encoding of main and testnet in WIF and BIP32 as legacy, that I ignore, and suggest that new BIPs should no longer carry this forward. Regards, Tamas Blummer http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Yes, it is current norm. I am questioning if we should hang on to it in BIPs. I see testnet as a tool for a certain type of testing. Its existence is likely a consequence of Satoshi not writing unit tests and having automated integration tests, but creating a shadow chain to try things out, mostly manually. I do not say testnet (as we know) would not be useful for certain tests. E.g. as we developed myTREZOR with slush it was useful to have a shared chain with worthless tokens and transactions we can both refer to. However for our automated tests chains-in-a-box are better as we can easily create and exactly re-create wierd situations on-the-fly. While talking about BIP32 hierarchy use, several people argued to use a level of the hierarchy to identify the chain the key is used on. That level could identify testnet but as well an alt coin chain. Above leads me thinking that testnet is far less important than to be addressed in every future BIP. Regards, Tamas Blummer http://bitsofproof.com On 22.04.2014, at 19:07, Jan Møller jan.mol...@gmail.com wrote: Treating testnet differently is quite the norm, we have that in BIP 32, 38, 70, SIPA private keys (no BIP for that I guess), bitcoin addresses etc. At the same time none of them define values for alt coins as far as I recall. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
The problem is µBTC that bit tries to solve. BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The mixed use of them leads to misunderstanding. I think adoption would benefit of a single unit with easily remembered and associated name that has no smaller than 1/100 fractions called satoshis. Regards, Tamás Blummer Founder, CEO http://bitsofproof.com On 23.04.2014, at 11:44, Danny Hamilton danny.hamil...@gmail.com wrote: It seems to me that xbit is no more distinct or intuitive than µbit. In either case it's simply an arbitrary character in front of the word bit. Of course, for the majority of the world familiar with SI, the µ actually adds additional meaning that is lost with the x. Furthermore, given the multiple concerns voiced about the overuse of the word bit, µBTC seems to solve the problem. Since we are talking about how it would be displayed in software, we don't need to be concerned about how people will pronounce it, or what the nickname will be. If most of the wallets start displaying amounts in µBTC quantities, it will be obvious that a µBTC is a different magnitude than a BTC. Nobody is going to look at their 100,000 µBTC balance and think they have 100,000 BTC. People will immediately make the mental adjustment to the new order of magnitude even if they don't specifically know that µ means micro, or that micro means 1e-6. Nicknames will form organically (much like buck, fin, large, k, grand, and benny for U.S. currency), I've always been partial to milly (or millie) and mike (or micky) as nicknames for mBTC and µBTC. I've personally used those when speaking with people, and they seem to catch on pretty quickly. As has already been mentioned, you're going to be hard pressed to find software that denotes U.S. balances in bucks. There isn't any good reason to be coding a nickname like bit, xbit, or mike into wallet software. - Danny Hamilton On Tue, Apr 22, 2014 at 8:51 AM, Aaron Axvig aa...@axvigs.com wrote: That piece of horse equipment is called a bit in the US too. But the point stands: most people don't use bit on a daily basis other than referring to a little bit of something. -Original Message- From: Wladimir [mailto:laa...@gmail.com] Sent: Sunday, April 20, 2014 11:27 AM To: Chris Pacia Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bits: Unit of account 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 -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java
Re: [Bitcoin-development] New BIP32 structure
The most useful meta data to optimize chain scan is the key birth date, then the allowed gap size. Tamas Blummer http://bitsofproof.com On 23.04.2014, at 20:39, Tier Nolan tier.no...@gmail.com wrote: Different users could have different gap limit requirements. 20 seems very low as the default. A merchant could easily send 20 addresses in a row to customers and none of them bother to actually buy anything. Setting the gap limit to high is just a small extra cost in that case. Bip-32 serialization doesn't have a way of adding meta data though. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] New BIP32 structure
I built such a merchant system handing out BIP32 addresses. The gap size problem does not arise there since such a system has to have an extra database keeping track of requests, so there is no added cost of storing the key coordinates used by them. A scan is not needed the keys can be accessed at random order. Tamas Blummer http://bitsofproof.com On 23.04.2014, at 21:00, Tier Nolan tier.no...@gmail.com wrote: On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak st...@gk2.sk wrote: Setting the gap limit to high is just a small extra cost in that case. Not if you have 100 accounts on 10 different devices. I meant for a merchant with a server that is handing out hundreds of addresses. The point is to have a single system that is compatible over a large number of systems. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] New BIP32 structure
Pieter suggested in IRC couple of months ago to append key birth to key serialization in xprv….@unixtime format. What about picking this idea up in BIP64? It would greatly help the importing client. Regards, Tamas Blummer http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] New BIP32 structure
On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the wallet, they are no longer associated with the address or any other details of how they were received. This is a bit idealistic. The wallet has to know how it got the UTXO in order to be able to spend it. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] New BIP32 structure
On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote: On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the wallet, they are no longer associated with the address or any other details of how they were received. This is a bit idealistic. The wallet has to know how it got the UTXO in order to be able to spend it. No it doesn't... Just the assigned scriptPubKey and secret(s) required to satisfy it. To know the secret it needs to know which key coordinate to use that is logically the same as knowing the address it used to receive it. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] New BIP32 structure
On 23.04.2014, at 22:09, Luke-Jr l...@dashjr.org wrote: On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote: On 04/23/2014 10:01 PM, Luke-Jr wrote: Yes, it should scan all possible (under the BIP-defined structure) branches regardless of which features it supports. So you suggest to scan for accounts, show balances but don't allow user to spend them? Does not seem right to me. Scan all branches for UTXOs, then you have the balance for the wallet. Account balances are metadata, so cannot be known from the seed alone. If you want to have a way to restore accounts, you must define some more detailed wallet file format (which could be built on top of this). On Wednesday, April 23, 2014 8:04:35 PM you wrote: On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote: On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: The wallet has to know how it got the UTXO in order to be able to spend it. No it doesn't... Just the assigned scriptPubKey and secret(s) required to satisfy it. To know the secret it needs to know which key coordinate to use that is logically the same as knowing the address it used to receive it. Sure, it *knows* what address was used to receive it. But at the point it's a UTXO, that address is no longer relevant. In context of BIP32 one does not store secrets but re-create them on-the-fly if needed using key coordinates known to the UTXO. Individual secrets per UTXO are about as irrelevant and accessible as addresses. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] BIP32 wallet structure in use? Remove it?
Yes, it is expensive but possible to discover any funds associated with a seed, provided there are set limits to: 1. gap of address use (e.g. 20) 2. depth of hierarchy (e.g. 6) 3. gap in use of parallel branches (e.g. 0) I would pick the limits in brackets above. Regards, Tamas Blummer http://bitsofproof.com On 26.04.2014, at 12:48, Tier Nolan tier.no...@gmail.com wrote: Maybe the solution is to have a defined way to import an unknown wallet? This means that the gap space and a search ordering needs to be defined. Given a blockchain and a root seed, it should be possible to find all the addresses for that root seed. The hierarchy that the wallet actually uses could be anything. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] BIP32 wallet structure in use? Remove it?
Actually gap in parallel branches already fails with BIP64 as it starts with m/64'/…. without having m/63' Regards, Tamas Blummer http://bitsofproof.com On 26.04.2014, at 12:59, Tamas Blummer ta...@bitsofproof.com wrote: Yes, it is expensive but possible to discover any funds associated with a seed, provided there are set limits to: 1. gap of address use (e.g. 20) 2. depth of hierarchy (e.g. 6) 3. gap in use of parallel branches (e.g. 0) I would pick the limits in brackets above. Regards, Tamas Blummer http://bitsofproof.com On 26.04.2014, at 12:48, Tier Nolan tier.no...@gmail.com wrote: Maybe the solution is to have a defined way to import an unknown wallet? This means that the gap space and a search ordering needs to be defined. Given a blockchain and a root seed, it should be possible to find all the addresses for that root seed. The hierarchy that the wallet actually uses could be anything. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] moving the default display to mbtc
Excellent move Jeff. Best would now be to establish XBT as the ISO code for bits. Regards, Tamas Blummer http://bitsofproof.com On 02.05.2014, at 21:17, Jeff Garzik jgar...@bitpay.com wrote: vendor hat: on Related: http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
bit has a lot of meanings to geeks, so what. bit means for average people: - something very small, that 100 satoshi is. - part of the name Bitcoin - easy to get conversion 1 coin = 1 million bits = 1 Bitcoin Regards, Tamas Blummer Founder, CEO http://bitsofproof.com On 03.05.2014, at 18:02, slush sl...@centrum.cz wrote: Excellent points Christophe! Although moving to 1e-6 units is fine for me and I see advantages of doing this, I don't get that people on this mailing list are fine with calling such unit bit. It's geeky as hell, ambiguous and confusing. slush On Sat, May 3, 2014 at 5:48 PM, 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? 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
Re: [Bitcoin-development] bits: Unit of account
Wladimir, what is missing is a decision to pull for the reference client. Or did I missed that bit? signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Plans to separate wallet from core
I think there are three typical uses: 1. Building consensus on the block chain. This is what the core is for. 2. Single user wallets. This is where SPV alone is good. 3. Services e.g. exchange, payment processor This is where core + indexing server talking SPV to core is the right choice Regards, Tamás Blummer Founder, CEO http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
Note that the problem might arise also by a bug / accident and not as an attack. Since value spent is not part of the signature it is easy to create an arbitrary fee by a defective wallet software. Collecting that huge fee might provide a higher incentive to miner than the block subsidy on the trunk. Assuming miner are fully rational, they might even form a temporary coalition to claim the fee: The miner who mines forking block might offer part of the fee gained in a similar transaction to other miners, so they help to extend his fork. A sufficiently high stake could trigger a long fork “battle” of ad-hoc coalitions. Addressing the known bug of the signature hash, that it does not include the value spent, would have other positive effects, e.g. for resource limited hardware wallets. Interpretation of an OP_NOP for a value hashing signature check were suggested by Alan Reiner discussed earlier on bitcointalk. Tamas Blummer -- Slashdot TV. Videos 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] The Bitcoin Freeze on Transaction Attack (FRONT)
Sergio, you can call this an ORBS attack or an attempt of ad-hoc coalition forming for a fork. Preparation Step: Include a transaction sending a sizable amount between two of your own addresses in every block. Miner can do this at zero cost in their own blocks. Execution: Embed into the preferred fork a transaction double spending the regular do-nothing transaction with one that offers a sufficiently high fee. This offers inceptive to rational miner to join the ad-hoc coalition for that fork. Attempting to form an ad-hoc coalition using above steps is open to anyone, just cheaper and easier to execute for a miner. Fortunately cost for (cumulative) proof-of-work creates a lower bound to the incentive that need to be offered. So your worry of times where block subsidy is low is unwarranted as cost of POW will be high. I do not think “disallowing” the implementation of rational mining is a viable option, since no one needs permission to implement whatever optimization he thinks is profitable and within the rules. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Slashdot TV. Videos 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] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Thanks Peter, Having tried to write a bug-for-bug compatible code with Satoshi, I can only second that it is rather close to impossible. The aim of BIP62 is noble, still it does not feel right for me to increase the complexity of the code with e.g. soft-fork-ready versioning. Freezing the consensus code, studying its bugs appears more appropriate to me. What we learn could define a hard fork or a better chain we migrate to as discussed by blockstream. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Peter, forking would work best with a freeze of the consensus code. Do you see any chance for that? Tamas Blummer On Nov 7, 2014, at 1:03 AM, Peter Todd p...@petertodd.org wrote: Forking the codebase, rather than rewriting it, best ensures that your code actually implements the protocol properly, is safe to use for mining, and actually gets used. Rewriting Bitcoin Core is a fun project, but it's terrible politics. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
We spend scarce resources external to the digital realm to create Bitcoin. Real world sacrifice is needed to avoid “nothing at stake” and sybil attacks. With Bitcoin we now have a scarce resource within the digital realm, so it appeals my intuition to re-use it for sacrifice instead of linking again an external, real world resource. In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them. The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance. Those who want to mine the side chain will assemble side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain. A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. The Bitcoin miner will include burn transactions because they offer Bitcoin fees. Bitcoin miner can not selectively block side chains since the hashes associated with the burn do not disclose which side chain or other project they are for. Here you have a “merged mining” that does not need Bitcoin miner support or even consent. Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in. The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin. Tamas Blummer Bits of Proof 1172380e63346e3e915b52fcbae838ba958948ac9aa85edd signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Isodor: Rational Miner will include burn transaction for fee, no doubt. Censoring transactions is against Bitcoin’s core values, unlikely to get wide support for any form of that. Patrick: Mining is at cost even if following the rules. No change to that. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Burn mining side chains might be one of the foundation ideas for that ecosystem, enabling permission-less merge mining for anyone with interest in a side chain. I am puzzled by the lack of feedback on the idea. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Peter,
Thanks for the research, I am glad that the idea, that proof-of-burn can
“transfer proof-of-work
was discussed earlier, as those discussions give some attack vectors that I can
reevaluate in
a new context, that is side chains.
I think that the lottery component I suggested, makes it much more resilient to
“outspend” attack, since
the attacker not only needs to outspend but win the lottery for a reorg. This
raises the cost of the attack
by magnitudes above the regular miner burn cost.
In addition, I suggest the burn transaction to include the Bitcoin block
height, thereby disabling re-use of a burn,
for a later reorg.
Tamas Blummer
Bits of Proof
On Dec 15, 2014, at 1:39 PM, Peter Todd p...@petertodd.org wrote:
On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
Burn mining side chains might be one of the foundation ideas for that
ecosystem, enabling permission-less merge mining for
anyone with interest in a side chain.
I am puzzled by the lack of feedback on the idea.
It's not a new idea actually - I outlined a system I eventually called
zookeyv¹ based on the notion of sacrificing Bitcoins to achieve
consensus a year and a half ago on #bitcoin-wizards. The discussion
started here and continued for a few days:
https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log
I later wrote up the idea in the context of adding Zerocoin to Bitcoin:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
For key-value mapping I eventually decided that the system didn't
necessarily need to be a strict linear blockchain - a directed acyclic
graph of commitments had advantages as there needed to be less
syncronization between transactions. This also means that the graph
doesn't necessarily need to be revealed directly in the blockchain,
exposing it to miner censorship. OTOH revealing it makes it easy to
determine if an attacker larger than you exists. These days I'd suggest
using timelock crypto to defeat miner censorship, while ensuring that in
principle consensus over all possible parts of the chain can eventually
be reached.²
Proof-of-sacrifice for consensus has a few weird properties. For
instance you can defeat attackers after the fact by simply sacrificing
more than the attacker. Not unlike having a infinite amount of mining
equipment available with the only constraint being funds to pay for the
electricity. (which *is* semi-true with altcoins!)
As for your specific example, you can improve it's censorship resistance
by having the transactions commit to a nonce in advance in some way
indistinguishable from normal transactions, and then making the
selection criteria be some function of H(nonce | blockhash) - for
instance highest wins. So long as the chain selection is based on
cumulative difficulty based on a fixed target - as is the case in
Bitcoin proper - you should get a proper incentive to publish blocks, as
well as the total work information rachet effect Bitcoin has against
attackers.
1) In honor of Zooko's triangle.
2) This doesn't necessarily take as much work as you might expect: you
can work backwards from the most recent block(s) if the scheme
requires block B_i to include the decryption key for block B_{i-1}.
--
'peter'[:-1]@petertodd.org
18d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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=164703151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
The output has to be burned otherwise there is no cost of expressing any number of alternate opinions the same time. Tamas Blummer Bits of Proof On Dec 15, 2014, at 3:55 PM, Isidor Zeuner cryptocurrenc...@quidecco.de wrote: For every participant who could try to decide about the adequateness of the cost, no direct effect comes from the difference between Proof of Burn, and approaches which keep the Bitcoins inside the set of outputs that can still participate. So, any notion which differentiates with respect to this must make some assumption about what defines the interest of the Bitcoin nodes as a community. Best regards, Isidor signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Let me be more concrete in implementation details: 1) burn transaction sends at least n satoshis to an OP_RETURN h, 2) h mod m matches the bitcoin block hash mod m, for the block the burn transaction was mined into. 3) The side chain block header hashes to h and also contains the bitcoin block hight. 4) a side chain block releases x new side coins Since the burn hash does not reveal in advance which side chain it will be used for, the Bitcoin miner can not selectively block burn mining. They will include loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over independent burn miner of the side chain. Anyone who issues a burn transaction that complies the rules 1-3 has 1/m the chance to win the next block on the side chain. This implies a fair exchange rate of n*m satoshis = x side coins (at the margin). Should two burn transactions fulfill the mod m lottery criteria, then we have a competing fork on the side chain. Just as for Bitcoin, the next block(s) will pick the winner. To contain fork rate, the parameter m would have to be adjusted dynamically, similar to Bitcoins difficulty. It needs to increase if fork rate increases and decrease if no valid block is burned with Bitcoin blocks. Unfortunately SPV can only prove the existence of a transaction, but not the non-existence of an alternative. Therefore the fork rate within a block cycle can not be evaluated with SPV proofs. Rational burn miner who frequently faces and loses head-to-head runs with a competing forks would increase his bet for the next burn cycle, as increasing the individual bet amount has the advantage that if he wins his victory is more stable. Remember the side chain trunk is selected as the one with highest cumulative burn. Consequently cumulative burn within an adjustment period (measured in Bitcoin blocks) is expected to rise in face of high fork rate. If the sample period burn exceeds a target, then it would trigger a rise to the lottery criteria m, reducing the fork rate and vs. Tamas Blummer Bits of Proof On Dec 10, 2014, at 8:35 AM, Tamas Blummer ta...@bitsofproof.com wrote: We spend scarce resources external to the digital realm to create Bitcoin. Real world sacrifice is needed to avoid “nothing at stake” and sybil attacks. With Bitcoin we now have a scarce resource within the digital realm, so it appeals my intuition to re-use it for sacrifice instead of linking again an external, real world resource. In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them. The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance. Those who want to mine the side chain will assemble side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain. A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. The Bitcoin miner will include burn transactions because they offer Bitcoin fees. Bitcoin miner can not selectively block side chains since the hashes associated with the burn do not disclose which side chain or other project they are for. Here you have a “merged mining” that does not need Bitcoin miner support or even consent. Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in. The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin. Tamas Blummer Bits of Proof 1172380e63346e3e915b52fcbae838ba958948ac9aa85edd signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Moving further with the Idea: Alternative to re-adjusting the lottery criteria, the side chain block candidate could be required to prove a work to be eligible for the burn lottery. A mix of required burn, work and luck could be tailored to achieve the desired 51% resilience” of the side chain. The side chain could use work for regular blocks and a much higher “difficulty” parent chain burn lottery for less frequent “checkpoints. Eg. the side chain difficulty of 1/n of Bitcoin is attainable for a small side chain miner community to advance its chain at Bitcoin’s speed. Simultaneously the block candidates would be submitted to a Bitcoin burn lottery with 1/n odds, so the security of the side chain roughly equals that of Bitcoin at every successful burn mined checkpoint. Tamas Blummer Bits of Proof On Dec 16, 2014, at 1:30 PM, Tamas Blummer ta...@bitsofproof.com wrote: Let me be more concrete in implementation details: 1) burn transaction sends at least n satoshis to an OP_RETURN h, 2) h mod m matches the bitcoin block hash mod m, for the block the burn transaction was mined into. 3) The side chain block header hashes to h and also contains the bitcoin block hight. 4) a side chain block releases x new side coins Since the burn hash does not reveal in advance which side chain it will be used for, the Bitcoin miner can not selectively block burn mining. They will include loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over independent burn miner of the side chain. Anyone who issues a burn transaction that complies the rules 1-3 has 1/m the chance to win the next block on the side chain. This implies a fair exchange rate of n*m satoshis = x side coins (at the margin). Should two burn transactions fulfill the mod m lottery criteria, then we have a competing fork on the side chain. Just as for Bitcoin, the next block(s) will pick the winner. To contain fork rate, the parameter m would have to be adjusted dynamically, similar to Bitcoins difficulty. It needs to increase if fork rate increases and decrease if no valid block is burned with Bitcoin blocks. Unfortunately SPV can only prove the existence of a transaction, but not the non-existence of an alternative. Therefore the fork rate within a block cycle can not be evaluated with SPV proofs. Rational burn miner who frequently faces and loses head-to-head runs with a competing forks would increase his bet for the next burn cycle, as increasing the individual bet amount has the advantage that if he wins his victory is more stable. Remember the side chain trunk is selected as the one with highest cumulative burn. Consequently cumulative burn within an adjustment period (measured in Bitcoin blocks) is expected to rise in face of high fork rate. If the sample period burn exceeds a target, then it would trigger a rise to the lottery criteria m, reducing the fork rate and vs. Tamas Blummer Bits of Proof On Dec 10, 2014, at 8:35 AM, Tamas Blummer ta...@bitsofproof.com wrote: We spend scarce resources external to the digital realm to create Bitcoin. Real world sacrifice is needed to avoid “nothing at stake” and sybil attacks. With Bitcoin we now have a scarce resource within the digital realm, so it appeals my intuition to re-use it for sacrifice instead of linking again an external, real world resource. In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them. The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance. Those who want to mine the side chain will assemble side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain. A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. The Bitcoin miner will include burn transactions because they offer Bitcoin fees. Bitcoin miner can not selectively block side chains since the hashes associated with the burn do not disclose which side chain or other project they are for. Here you have a “merged mining
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
Justus, In contrary. Not being in the jurisdiction of the wallet provider makes it harder for the user to reclaim funds taken by the wallet provider. The legal hurdle to force confiscation through a wallet provider might also be lower if the target user is not domestic. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
Knowing the private key and owning the linked coins is not necessarily the same in front of a court. At least in german law there is a difference between ‘Eigentum' means ownership and ‘Besitz’ means ability to deal with it. Being able to deal with an asset does not make you the owner. Tamas Blummer On Jan 20, 2015, at 6:23 PM, Matt Whitlock b...@mattwhitlock.name wrote: If you have the private keys for your users' bitcoins, then you are every bit as much the owner of those bitcoins as your users are. There is no custodial relationship, as you have both the ability and the right to spend those bitcoins. Possession of a private key is equivalent to ownership of the bitcoins controlled by that private key. signature.asc Description: Message signed with OpenPGP using GPGMail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
I am not a lawyer, just thinking loud. I think that technology is a strong argument before court, but I suspect that it is just that, as of now. Tamas Blummer On Jan 20, 2015, at 6:47 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Tuesday, 20 January 2015, at 6:44 pm, Tamas Blummer wrote: Knowing the private key and owning the linked coins is not necessarily the same in front of a court. At least in german law there is a difference between ‘Eigentum' means ownership and ‘Besitz’ means ability to deal with it. Being able to deal with an asset does not make you the owner. So what we're telling the newbies in /r/bitcoin is plain wrong. Bitcoins *do* have an owner independent from the parties who have access to the private keys that control their disposition. That's pretty difficult to reconcile from a technological perspective. signature.asc Description: Message signed with OpenPGP using GPGMail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Feb 12, 2015, at 9:16 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: Why don't you use getrawmempool RPC call to synchronize mempool contents? Since RPC interface does not scale to serve a multi user service. In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus. POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to. On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic . Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Peter, An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Feb 19, 2015, at 3:03 PM, Bryan Bishop kanz...@gmail.com wrote: First, I strongly disagree with voting here for reasons that I hope others will elaborate on. I meant voting by pledging on the lighthouse project, not here on the list. Sorry for not stating this explicitelly. Second, I think that squeezing all possible language bindings into a project is also unproductive. The language binding would be an independent and separately hosted project only using the C interface of the libconsensus library. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
[Bitcoin-development] var_int ambiguous serialization consequences
I wonder of consequences if var_int is used in its longer than necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01) This is already of interest if applying size limit to a block, since transaction count is var_int but is not part of the hashed header or the merkle tree. It could also be used to create variants of the same transaction message by altered representation of txIn and txout counts, that would remain valid provided signatures validate with the shortest form, as that is created while re-serializing for signature hashing. An implementation that holds mempool by raw message hashes could be tricked to believe that a modified encoded version of the same transaction is a real double spend. One could also mine a valid block with transactions that have a different hash if regularly parsed and re-serialized. An SPV client could be confused by such a transaction as it was present in the merkle tree proof with a different hash than it gets for the tx with its own serialization or from the raw message. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
Peter, You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: So stop wasting your time. Help get the consensus critical code out of Bitcoin Core and into a stand-alone libconsensus library, We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P service rules, wallet and RPC server. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: Or you can be stereotypical programmers and dick around on github for the next ten years chasing stupid consensus bugs in code no-one uses. The Core code base is unfriendly to feature extensions because of its criticality, legacy design and ancient technology. It is also a commodity that the ecosystem takes for granted and free. I honestly admire the core team that works and progresses within these limits and perception. I am not willing to work within the core’s legacy technology limits. Does it mean I am dicking around? I think not. It was my way to go down the rabbit hole by re-digging it and I created successful commercial products on the way. It is entirely rational for me to focus on innovation that uses the core as a border router for this block chain. I am rather thankful for the ideas of the side chains, that enable innovation that is no longer measured on unapologetic compatibility with a given code base, but its services to end user. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Mike, You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some. Some other’s might have seen the replaced transaction, but that only indicates for sure that the signer is fraudulent. What should a node do that really cares of good reputation? Ignore both to be on the safe side? Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Feb 12, 2015, at 3:16 PM, Mike Hearn m...@plan99.net wrote: You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some. Fraudulent in what sense? Assume a wallet that sends double spend of the coin spent for services with higher fees to some of its nodes simultaneously. Merchants will catch and reject most of the attempts, but that will not stop the scheme in a setup where customer are anonymous and distant. Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Mike, Peter’s pull request might be a foot gun, but we are here to find out. One can’t claim Bitcoin core code is there to fork and then be disappointed if some really do it. I am not sure protecting unconfirmed transactions ranks higher than fostering innovation not to depend on the same. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Feb 12, 2015, at 9:49 AM, Peter Todd p...@petertodd.org wrote: How does my replace-by-fee patch *not* do that? Does it broadcast a double spend only if it IS replacing an earlier? If yes, I am fine with it. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Feb 15, 2015, at 6:02 PM, Peter Todd p...@petertodd.org wrote: Yes you are dicking around. I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface. The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging and now comes handy to create a side chain. Don't assume your prior experience with other commercial projects Acquire some before you claim its useless. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bloom filtering, privacy
On Feb 20, 2015, at 5:18 PM, Wladimir laa...@gmail.com wrote: On Fri, 20 Feb 2015, Adam Back wrote: So I was wondering what about changing to committing a bloom filter of the addresses in the block. Its seems surprising no one thought of it that way before (as it seems obvious when you hear it) but that seems Such a bloom filter was present in the Bits of Proof block store in its last public version, so the idea obvious, but not new. It did support well scanning for BIP32 addresses as the query set extends while progressing. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] SIGHASH_WITHINPUTVALUE
Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
You mean an isolated signing device without memory right? An isolated node would still know the transactions substantiating its coins, why would it sign them away to fees ? Tamas Blummer On Jan 23, 2015, at 4:47 PM, slush sl...@centrum.cz wrote: Correct, plus the most likely scenario in such attack is that the malware even don't push such tx with excessive fees to the network, but send it directly to attacker's pool/miner. M. On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner etothe...@gmail.com wrote: Unfortunately, one major attack vector is someone isolating your node, getting you to sign away your whole wallet to fee, and then selling it to a mining pool to mine it before you can figure why your transactions aren't making it to the network. In such an attack, the relay rules aren't relevant, and if the attacker can DoS you for 24 hours, it doesn't take a ton of mining power to make the attack extremely likely to succeed. On 01/23/2015 10:31 AM, Tamas Blummer wrote: Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
