Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Tamas Blummer
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] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

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


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

2015-02-15 Thread Tamas Blummer

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] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

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

2015-02-12 Thread Tamas Blummer


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

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

2015-02-12 Thread Tamas Blummer

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

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

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 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

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


[Bitcoin-development] var_int ambiguous serialization consequences

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

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 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


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


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

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 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

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:
 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] Merged mining a side chain with proof of burn on parent chain

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

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

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 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

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

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


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


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

2014-12-09 Thread Tamas Blummer

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] 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 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


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

2014-11-06 Thread Tamas Blummer
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 Bitcoin Freeze on Transaction Attack (FRONT)

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

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

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] 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 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

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, 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] 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-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] 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://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?

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 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] 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 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

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 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

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

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 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

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 
 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

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 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

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

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 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

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 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

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

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

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

2014-04-21 Thread Tamas Blummer
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] bits: Unit of account

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

2014-04-20 Thread Tamas Blummer
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] Bitcoind-in-background mode for SPV wallets

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

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

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

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

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 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] Bitcoind-in-background mode for SPV wallets

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

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 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

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://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] Why are we bleeding nodes?

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

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:

 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] 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 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?

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

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

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

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 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?

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

2014-04-07 Thread Tamas Blummer
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

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

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

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

2014-03-29 Thread Tamas Blummer
I also think that we can add usability features if the underlying secret 
remains well protected.
I do not think there is any reason to assume that the knowledge of the degree 
of the polynomial, would aid an attacker.

Similarly a fingerprint of the secret if it is unrelated to the hash used 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, at 18:52, Alan Reiner etothe...@gmail.com wrote:

 On 03/29/2014 01:19 PM, Matt Whitlock wrote:
 I intentionally omitted the parameter M (minimum subset size) from the 
 shares because including it would give an adversary a vital piece of 
 information. Likewise, including any kind of information that would allow a 
 determination of whether the secret has been correctly reconstituted would 
 give an adversary too much information. Failing silently when given 
 incorrect shares or an insufficient number of shares is intentional.
 
 I do not believe this is a good tradeoff.  It's basically obfuscation of
 something that is already considered secure at the expense of
 usability.  It's much more important to me that the user understands
 what is in their hands (or their family members after they get hit by a
 bus), than to obfuscate the parameters of the secret sharing to provide
 a tiny disadvantage to an adversary who gets ahold of one. 
 
 The fact that it fails silently is really all downside, not a benefit. 
 If I have enough fragments, I can reconstruct the seed and see that it
 produces addresses with money.  If not, I know I need more fragments. 
 I'm much more concerned about my family having all the info they need to
 recover the money, than an attacker knowing that he needs two more
 fragments instead of which are well-secured anyway.
 
 
 
 --
 ___
 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

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 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] 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 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

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

2014-03-28 Thread Tamas Blummer

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

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 
 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

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 
 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

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 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

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.
 
 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

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

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

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

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: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] moving the default display to mbtc

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

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

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

2014-03-13 Thread Tamas Blummer

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

2014-03-13 Thread Tamas Blummer
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] 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, 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] 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
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] Making fee estimation better

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



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] 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

--
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] Missing fRelayTxes in version

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

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

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

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