Re: [Bitcoin-development] Modularizing Bitcoin

2013-05-26 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP0032

2013-05-27 Thread Tamas Blummer
/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

Re: [Bitcoin-development] Missing fRelayTxes in version

2013-06-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] Missing fRelayTxes in version

2013-06-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] Missing fRelayTxes in version

2013-06-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-17 Thread Tamas Blummer
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

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 (Gavin Andresen)

2013-07-31 Thread Tamas Blummer
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

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9

2014-02-24 Thread Tamas Blummer
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

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Tamas Blummer
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

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Tamas Blummer
://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

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Tamas Blummer
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

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Tamas Blummer
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

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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.

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Tamas Blummer
, 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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread Tamas Blummer
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread Tamas Blummer
, 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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread Tamas Blummer
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread Tamas Blummer
in the polinomyal should leak no useful information, The length of such fingerpring (say 4 bytes) and the degree (1 byte) does not seem a big overhead for me. Remember that the biggest obstacle of Bitcoin is usability not security. Regards, Tamas Blummer http://bitsofproof.com On 29.03.2014

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread Tamas Blummer
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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Tamas Blummer
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

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-08 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread Tamas Blummer
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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Tamas Blummer
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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Tamas Blummer
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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Tamas Blummer
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

Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] bits: Unit of account

2014-04-21 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] bits: Unit of account

2014-04-21 Thread Tamas Blummer
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

Re: [Bitcoin-development] bits: Unit of account

2014-04-21 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
It is not about taste, but the fact that BIPs are used by many chains. Alts are useful for at least for experiments, and I think that the notion of main and testnet is superseeded by a wide choice of chains. Regards, Tamas Blummer http://bitsofproof.com signature.asc Description: Message

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
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

Re: [Bitcoin-development] bits: Unit of account

2014-04-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Tamas Blummer
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

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Tamas Blummer
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

Re: [Bitcoin-development] moving the default display to mbtc

2014-05-02 Thread Tamas Blummer
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

Re: [Bitcoin-development] bits: Unit of account

2014-05-03 Thread Tamas Blummer
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

Re: [Bitcoin-development] bits: Unit of account

2014-05-04 Thread Tamas Blummer
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

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Tamas Blummer
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

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

2014-10-06 Thread Tamas Blummer
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

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

2014-10-06 Thread Tamas Blummer
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

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

2014-11-06 Thread Tamas Blummer
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

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

2014-11-07 Thread Tamas Blummer
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

[Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-09 Thread Tamas Blummer
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

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-11 Thread Tamas Blummer
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

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-15 Thread Tamas Blummer
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

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-15 Thread Tamas Blummer
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

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Tamas Blummer
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

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Tamas Blummer
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

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-18 Thread Tamas Blummer
. 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

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Tamas Blummer
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

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

2015-02-12 Thread Tamas Blummer
. 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

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

2015-02-11 Thread Tamas Blummer
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

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

2015-02-19 Thread Tamas Blummer
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

[Bitcoin-development] var_int ambiguous serialization consequences

2015-02-01 Thread Tamas Blummer
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

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

2015-02-14 Thread Tamas Blummer
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

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

2015-02-12 Thread Tamas Blummer
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

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

2015-02-12 Thread Tamas Blummer
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

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

2015-02-12 Thread Tamas Blummer
. 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

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

2015-02-12 Thread Tamas Blummer
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

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

2015-02-15 Thread Tamas Blummer
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

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Tamas Blummer
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

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Tamas Blummer
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

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Tamas Blummer
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