Re: [Bitcoin-development] bloom filtering, privacy
On Feb 20, 2015, at 5:18 PM, Wladimir 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=190641631&iu=/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?)
On Feb 19, 2015, at 3:03 PM, Bryan Bishop 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=190641631&iu=/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?)
On Feb 19, 2015, at 6:22 AM, Tamas Blummer wrote: > I launched a Lighthouse project to add Java Language Binding to lib > consensus. Let's turn the debate to a constructive vote. > > See on https://www.reddit.com/r/LighthouseProjects I should have added the project description here, as above is only readable with lighthouse: Java Language Binding for Core Consensus Library Bitcoin Core 0.10.0 comes with a library for external services that validates Bitcoin transactions with the code base of the core. The proposed language binding would unleash innovation of JVM application developer without raising concern of a network fork through incompatible alternate implementations of the protocol. The language binding would be written with lightweight, immutable, self contained data classes that use only language standard libraries, therefore suitable for any service framework. 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=190641631&iu=/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?)
Libconsensus will create an in-process alternative to the border router setup I currently advocate in a production environment. It is not sufficient yet, since only checking scripts, but is the move I was long waiting for. I launched a Lighthouse project to add Java Language Binding to lib consensus. Let's turn the debate to a constructive vote. See on https://www.reddit.com/r/LighthouseProjects 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=190641631&iu=/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?)
On Feb 15, 2015, at 6:02 PM, Peter Todd 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?)
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 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 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
On Feb 12, 2015, at 3:16 PM, Mike Hearn wrote: > You can not consider the outcome resulting by replace-by-fee fraudulent, as > it could be the world as observed by some. > > Fraudulent in what sense? Assume a wallet that sends double spend of the coin spent for services with higher fees to some of its nodes simultaneously. Merchants will catch and reject most of the attempts, but that will not stop the scheme in a setup where customer are anonymous and distant. Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Mike, 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
Mike, Peter’s pull request might be a foot gun, but we are here to find out. One can’t claim Bitcoin core code is there to fork and then be disappointed if some really do it. I am not sure protecting unconfirmed transactions ranks higher than fostering innovation not to depend on the same. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Feb 12, 2015, at 9:49 AM, Peter Todd 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
On Feb 12, 2015, at 9:16 AM, Alex Mizrahi 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 wrote: > IOW, assume every transaction your "border router" gives you is now the > one and only true transaction, and everything conflicting with it must > go. You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic . Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Peter, An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] var_int ambiguous serialization consequences
Thanks for the clarification. Yes, I referred to CompactSize using the lingo of https://en.bitcoin.it/wiki/Protocol_documentation I am not sure if it is current concern. Apparently an exception is thrown if non-canonical CompactSize in a transaction s parsed. Is it ensured that transactions are always parsed before computing their hash? Tamas Blummer On Feb 1, 2015, at 11:44 AM, Wladimir wrote: > > On Sun, 1 Feb 2015, Tamas Blummer wrote: > >> I wonder of consequences if var_int is used in its longer than necessary >> forms (e.g encoding 1 as 0xfd0100 instead of 0x01) > > In serialize.h lingo you are talking about CompactSize, not VarInt. > > CompactSizes indeed have redundancy in their representation, i.e. the same > number can be represented as up to four different byte sequences. > > VARINTs have a different format that (AFAIK) isn't used anywhere in the block > chain. See WriteVarInt / ReadVarInt. These were designed to not have any > redundancy in their representation. > >> 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. > > Are you sure that this is a current concern? Non-canonical CompactSizes are > forbidden - in serialize.h this is flagged in ReadCompactSize. > > Wladimir > > 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
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
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 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 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] SIGHASH_WITHINPUTVALUE
Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
Justus, In contrary. Not being in the jurisdiction of the wallet provider makes it harder for the user to reclaim funds taken by the wallet provider. The legal hurdle to force confiscation through a wallet provider might also be lower if the target user is not domestic. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
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 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] The legal risks of auto-updating wallet software; custodial relationships
Knowing the private key and owning the linked coins is not necessarily the same in front of a court. At least in german law there is a difference between ‘Eigentum' means ownership and ‘Besitz’ means ability to deal with it. Being able to deal with an asset does not make you the owner. Tamas Blummer On Jan 20, 2015, at 6:23 PM, Matt Whitlock 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] Merged mining a side chain with proof of burn on parent chain
Moving further with the Idea: Alternative to re-adjusting the lottery criteria, the side chain block candidate could be required to prove a work to be eligible for the burn lottery. A mix of required burn, work and luck could be tailored to achieve the desired "51% resilience” of the side chain. The side chain could use work for regular blocks and a much higher “difficulty” parent chain burn lottery for less frequent “checkpoints". Eg. the side chain difficulty of 1/n of Bitcoin is attainable for a small side chain miner community to advance its chain at Bitcoin’s speed. Simultaneously the block candidates would be submitted to a Bitcoin burn lottery with 1/n odds, so the security of the side chain roughly equals that of Bitcoin at every successful burn mined checkpoint. Tamas Blummer Bits of Proof On Dec 16, 2014, at 1:30 PM, Tamas Blummer 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 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 >&g
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Let me be more concrete in implementation details: 1) burn transaction sends at least n satoshis to an OP_RETURN h, 2) h mod m matches the bitcoin block hash mod m, for the block the burn transaction was mined into. 3) The side chain block header hashes to h and also contains the bitcoin block hight. 4) a side chain block releases x new side coins Since the burn hash does not reveal in advance which side chain it will be used for, the Bitcoin miner can not selectively block burn mining. They will include loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over independent burn miner of the side chain. Anyone who issues a burn transaction that complies the rules 1-3 has 1/m the chance to win the next block on the side chain. This implies a fair exchange rate of n*m satoshis = x side coins (at the margin). Should two burn transactions fulfill the mod m lottery criteria, then we have a competing fork on the side chain. Just as for Bitcoin, the next block(s) will pick the winner. To contain fork rate, the parameter m would have to be adjusted dynamically, similar to Bitcoins difficulty. It needs to increase if fork rate increases and decrease if no valid block is burned with Bitcoin blocks. Unfortunately SPV can only prove the existence of a transaction, but not the non-existence of an alternative. Therefore the fork rate within a block cycle can not be evaluated with SPV proofs. Rational burn miner who frequently faces and loses head-to-head runs with a competing forks would increase his bet for the next burn cycle, as increasing the individual bet amount has the advantage that if he wins his victory is more stable. Remember the side chain trunk is selected as the one with highest cumulative burn. Consequently cumulative burn within an adjustment period (measured in Bitcoin blocks) is expected to rise in face of high fork rate. If the sample period burn exceeds a target, then it would trigger a rise to the lottery criteria m, reducing the fork rate and vs. Tamas Blummer Bits of Proof On Dec 10, 2014, at 8:35 AM, Tamas Blummer 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 a
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
The output has to be burned otherwise there is no cost of expressing any number of alternate opinions the same time. Tamas Blummer Bits of Proof On Dec 15, 2014, at 3:55 PM, Isidor Zeuner 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=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Peter,
Thanks for the research, I am glad that the idea, that proof-of-burn can
“transfer" proof-of-work
was discussed earlier, as those discussions give some attack vectors that I can
reevaluate in
a new context, that is side chains.
I think that the lottery component I suggested, makes it much more resilient to
“outspend” attack, since
the attacker not only needs to outspend but win the lottery for a reorg. This
raises the cost of the attack
by magnitudes above the regular miner burn cost.
In addition, I suggest the burn transaction to include the Bitcoin block
height, thereby disabling re-use of a burn,
for a later reorg.
Tamas Blummer
Bits of Proof
On Dec 15, 2014, at 1:39 PM, Peter Todd 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=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Burn mining side chains might be one of the foundation ideas for that ecosystem, enabling permission-less merge mining for anyone with interest in a side chain. I am puzzled by the lack of feedback on the idea. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Isodor: Rational Miner will include burn transaction for fee, no doubt. Censoring transactions is against Bitcoin’s core values, unlikely to get wide support for any form of that. Patrick: Mining is at cost even if following the rules. No change to that. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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
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=164703151&iu=/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
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 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
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)
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=160591471&iu=/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)
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=160591471&iu=/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
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
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
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 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 > 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 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 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
Re: [Bitcoin-development] moving the default display to mbtc
Excellent move Jeff. Best would now be to establish XBT as the ISO code for bits. Regards, Tamas Blummer http://bitsofproof.com On 02.05.2014, at 21:17, Jeff Garzik wrote: > > > 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?
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 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 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?
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 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] New BIP32 structure
On 23.04.2014, at 22:09, Luke-Jr 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 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] New BIP32 structure
On 23.04.2014, at 22:02, Luke-Jr wrote: > On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: >> On 23.04.2014, at 21:55, Luke-Jr wrote: >>> Any wallet should import all the coins just fine, it just wouldn't *use* >>> any account other than 0. Remember addresses are used to receive >>> bitcoins; once the UTXOs are in the wallet, they are no longer >>> associated with the address or any other details of how they were >>> received. >> >> This is a bit idealistic. >> The wallet has to know how it got the UTXO in order to be able to spend it. > > No it doesn't... Just the assigned scriptPubKey and secret(s) required to > satisfy it. > To know the secret it needs to know which key coordinate to use that is logically the same as knowing the address it used to receive it. signature.asc Description: Message signed with OpenPGP using GPGMail -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 23.04.2014, at 21:55, Luke-Jr 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
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
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 wrote: > On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak 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
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 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] "bits": Unit of account
The problem is µBTC that bit tries to solve. BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The mixed use of them leads to misunderstanding. I think adoption would benefit of a single unit with easily remembered and associated name that has no smaller than 1/100 fractions called satoshis. Regards, Tamás Blummer Founder, CEO http://bitsofproof.com On 23.04.2014, at 11:44, Danny Hamilton 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 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 ." > > -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 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 Enterpr
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
So you agree, that SSS should not contain specific flag for testnet? Or for that matter not even BIP32 needs them since it is not an address to send to. Regards, Tamas Blummer http://bitsofproof.com On 22.04.2014, at 20:46, Gregory Maxwell wrote: > Testnet is not normally addressed in BIPs at all, except for soft fork > bips that had compressed deployment schedules on testnet. For address > like specification we have always used a version byte and there is a > common encoding for version bytes that flags the network ID in the > byte. > signature.asc Description: Message signed with OpenPGP using GPGMail -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Yes, it is current norm. I am questioning if we should hang on to it in BIPs. I see testnet as a tool for a certain type of testing. Its existence is likely a consequence of Satoshi not writing unit tests and having automated integration tests, but creating a shadow chain to try things out, mostly manually. I do not say testnet (as we know) would not be useful for certain tests. E.g. as we developed myTREZOR with slush it was useful to have a shared chain with worthless tokens and transactions we can both refer to. However for our automated tests chains-in-a-box are better as we can easily create and exactly re-create wierd situations on-the-fly. While talking about BIP32 hierarchy use, several people argued to use a level of the hierarchy to identify the chain the key is used on. That level could identify testnet but as well an alt coin chain. Above leads me thinking that testnet is far less important than to be addressed in every future BIP. Regards, Tamas Blummer http://bitsofproof.com On 22.04.2014, at 19:07, Jan Møller 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
I use several test chains while testing my software, the official test net, a standalone net in house and even chains only created on the fly for unit tests. I found no use of distinguishing serialization of keys while using any of them. If you have some deep insights about why this is needed share it, as I am not goint to guess your valuable thoughts. Regards, Tamas Blummer http://bitsofproof.com On 22.04.2014, at 17:32, Mark Friedenbach wrote: > Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin. > Unfortunately few of the alts ever figured this out. 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
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
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
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 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] "bits": Unit of account
xbit is close to XBT because it would be the same unit, both would mean 100 satoshi or 1e-6 Bitcoin. xbit would be for everyday use, XBT for ISO. I know, the XBT was used by some sites to be a synonym for BTC that is however in my opinion not yet graved in stone until it is used by e.g. Bloomberg. Regards, Tamas Blummer http://bitsofproof.com On 21.04.2014, at 14:14, Un Ix 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
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
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 wrote: > > On Apr 21, 2014 3:37 AM, "Un Ix" 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
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 wrote: > > On Apr 21, 2014 3:37 AM, "Un Ix" wrote: > > > > Something tells me this would be reduced to a single syllable in common > > usage I.e. bit. > > What units will be called colloquially is not something developers will > determine. It will vary, depend on language and culture, and is not relevant > to this discussion in my opinion. > > It may well be that people in some geographic or language area will end up > (or for a while) calling 1e-06 BTC "bits". That's fine, but using that as > "official" name in software would be very strange and potentially confusing > in my opinion. As mentioned by others, that would seem to me like calling > dollars "bucks" in bank software. Nobody seems to have a problem with having > colloquial names, but "US dollar" or "euro" are far less ambiguous than > "bit". I think we need a more distinctive name. > > -- > Pieter > -- > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "bits": Unit of account
Here is 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 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 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 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
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 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 > 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] Bitcoind-in-background mode for SPV wallets
Thanks, Peter and you convinced me. I run away with a thought. It’d be great to find a spot to deploy payment channels, but I agree this is not it. Tamas Blummer http://bitsofproof.com On 10.04.2014, at 12:40, Mike Hearn 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
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 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
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 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
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 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
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 wrote: > Signed PGP part > > > On 9 April 2014 12:27:13 GMT-04:00, Tamas Blummer > wrote: > >A border router that is not able to serve blocks is still protecting > >consensus rules, that SPVs do not. > >If the network would only consist of SPV nodes only then e.g. a > >majority coalition of miner could increase their reward at will. > > > >Archives need a different solution. > > Any collective group that has a majority of hashing power will have no major > issues running enough nodes that follow their rules to make SPV insecure > anyway. > > There's no good reason not to have SPV security nodes distribute block chain > data, particularly block headers. It helps provide redundancy in the network > topology and helps provide more resources for full nodes to sync up faster. > For instance in a network with a large number of partial UTXO set nodes if > those nodes are forwarding block data to each other they can get enough data > to become fully fledged full nodes without putting all the load on the > existing full nodes. This is a good thing. > > > signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
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. Regards, Tamas Blummer http://bitsofproof.com On 09.04.2014, at 17:47, Mark Friedenbach wrote: > On 04/09/2014 09:09 AM, Tamas Blummer wrote: >> 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. > > Storing zero full blocks does nothing to aid the network. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
I am glad that SPV wallets are discussed outside the scope of mobile devices! Yes, SPV is a sufficient API to a trusted node to build sophisticated features not offered by the core. SPV clients of the border router will build their own archive and indices based on their interest of the chain therefore the border router core does not need to store (and process) anything not needed for consensus, its memory or disk footprint would be as low as an optimal storage of UTXO. Regards, Tamás Blummer http://bitsofproof.com On 09.04.2014, at 17:57, Gregory Maxwell wrote: > On Wed, Apr 9, 2014 at 8:42 AM, Brian Hoffman 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
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 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] New BIP32 structure
Pieter, your suggestion has charm since “Bitcoin seed” would even not need a global dictionary like the interpretation of the first level, since it would be self describing. Regards, Tamas Blummer http://bitsofproof.com On 08.04.2014, at 15:53, Pieter Wuille 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 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 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?
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 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 wrote: >> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer 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] Why are we bleeding nodes?
You have to load headers sequantially to be able to connect them and determine the longest chain. Blocks can be loaded in random order once you have their order given by the headers. Computing the UTXO however will force you to at least temporarily store the blocks unless you have plenty of RAM. Regards, Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:30, Paul Lyon 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 wrote: > >> On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer wrote: >>> therefore I guess it is more handy to return some bitmap of pruned/full >>> blocks than ranges. >> >> A bitmap also means high overhead and— if it's used to advertise >> non-contiguous blocks— poor locality, since blocks are fetched >> sequentially. >> > > > -- > Put Bad Developers to Shame Dominate Development with Jenkins Continuous > Integration Continuously Automate Build, Test & Deployment Start a new > project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees > ___ Bitcoin-development mailing > list > Bitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
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 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?
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 wrote: > On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer 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?
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 wrote: > On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer wrote: >> Once a single transaction in pruned in a block, the block is no longer >> eligible to be served to other nodes. >> Which transactions are pruned can be rather custom e.g. even depending on >> the wallet(s) of the node, >> therefore I guess it is more handy to return some bitmap of pruned/full >> blocks than ranges. > > This isn't at all how pruning works in Bitcoin-QT (nor is it how I > expect pruning to work for any mature implementation). Pruning can > work happily on a whole block at a time basis regardless if all the > transactions in it are spent or not. > signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Once 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 wrote: > On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer 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?
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 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=r0BXnWlnIi4&feature=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?
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 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] Finite monetary supply for Bitcoin
While at that let's allow coin bases to be merged from orphan blocks, so miner are fairly rewarded even if unlucky. On 01.04.2014, at 21:00, Pieter Wuille wrote: > Hi all, > > I understand this is a controversial proposal, but bear with me please. > > I believe we cannot accept the current subsidy schedule anymore, so I > wrote a small draft BIP with a proposal to turn Bitcoin into a > limited-supply currency. Dogecoin has already shown how easy such > changes are, so I consider this a worthwhile idea to be explored. > > The text can be found here: https://gist.github.com/sipa/9920696 > > Please comment! > > Thanks, > > -- > Pieter > > -- > ___ > 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
On 29.03.2014, at 18:46, Gregory Maxwell 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
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 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
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 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
This is why my motivation is rather secure backup, not multisig. Instead of storing encrypted seed in one location and the passphrase for it in an other location, one can just store two shares in two places. > Right - the explanation in the BIP about the board of directors is IMO a > little misleading. The problem is with splitting a private key is that at > some point, someone has to get the full private key back and they can then > just remember the private key to undo the system. CHECKMULTISIG avoids this. > > I can imagine that there may be occasional uses for splitting a wallet seed > like this, like for higher security cold wallets, but I suspect an ongoing > shared account like a corporate account is still best off using CHECKMULTISIG > or the n-of-m ECDSA threshold scheme proposed by Ali et al. > > > On Sat, Mar 29, 2014 at 2:27 PM, Jeff Garzik wrote: > The comparison with multisig fails to mention that multi-signature > transactions explicitly define security at the transaction level. > This permits fine-grained specificity of what a key holder may > approve. > > Shamir is much more coarse-grained. You reconstitute a private key, > which may then be used to control anything that key controls. Thus, > in addition to Shamir itself, you need policies such as "no key > reuse." > > My first impression of Shamir many moons ago was "cool!" but that's > since been tempered by thinking through the use cases. Shamir has a > higher D.I.Y. factor, with a correspondingly larger surface of > things-that-could-go-wrong, IMO. > > (None of this implies making an informational BIP lacks value; I'm all > for an informational BIP) > > > > > On Sat, Mar 29, 2014 at 7:54 AM, Chris Beams wrote: > > Enlightening; thanks, Matt. And apologies to the list for my earlier > > inadvertent double-post. > > > > On Mar 29, 2014, at 12:16 PM, Matt Whitlock wrote: > > > >> On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote: > >>> Matt, could you expand on use cases for which you see Shamir's Secret > >>> Sharing Scheme as the best tool for the job? In particular, when do you > >>> see that it would be superior to simply going with multisig in the first > >>> place? Perhaps you see these as complimentary approaches, toward > >>> defense-in-depth? In any case, the Motivation and Rationale sections of > >>> the BIP in its current form are silent on these questions. > >> > >> I have added two new sections to address your questions. > >> > >> https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki > > > > > > -- > > > > ___ > > 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/ > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Hi Matt, I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key. Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed. Regards, Tamas Blummer http://bitsofproof.com On 29.03.2014, at 09:05, Matt Whitlock 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
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 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] BIP 70 refund field
May I ask how the current payment protocol is supposed to handle salaries? I hope you do not assume the employee creates a payment request, since he does not even calculate the amount. There you go where a channel I described is definitelly needed. Tamas Blummer http://bitsofproof.com On 28.03.2014, at 12:30, Tamas Blummer 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 wrote: > >> Modern devices like smartphones and tablets do not have swap files. This >> design is chosen to ensure responsive, fluid UI that can avoid blocking on >> disk regardless of how much multi-tasking is done, but it creates ripples >> that impact everything else. >> >> One implication of this is that on these devices, we cannot store all keys >> or transactions in memory forever. BIP 70 has an expiry field for >> PaymentRequests that we can use to allow us to eventually stop loading those >> keys into RAM - at that point payments to those keys would no longer be >> recognised. But there's no equivalent for refund addresses. >> >> More generally, though we re-used the output structure to define the refund, >> we didn't (for some reason that I forgot) reuse PaymentDetails, even though >> the payment details for a refund are indeed PaymentDetails. >> >> Though I am loathe to go back and redesign this part of BIP 70 so soon after >> we shipped v1, it seems to me like the refund feature may be hard to >> implement on phones if there's no time limit for when you can receive a >> refund. Otherwise a wallet has to be looking out for refunds for payments >> you may have made years ago. So perhaps we should add a new refund field >> that embeds a PaymentDetails structure instead of being just a list of >> outputs. >> >> We could try and solve this problem some other way purely internally, by >> doing a kind of wallet-specific swapping process in which things like Bloom >> filters are calculated without all keys in them being held in memory at once >> (perhaps caching filters for old parts of the key chain on disk), so you can >> have "infinite" wallets, but eventually the huge Bloom filters that would >> result would hurt efficiency in other ways. So key expiry seems pretty >> fundamental to scalability. >> >> >> -- >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
I have nothing against incremental development. This will however not pick up until it offers some incremental benefit compared to current payment processor solutions, such as e.g. 1. Symmetrical. One can also offer a payment. 2. Aggregating and Netting. Handle multiple installments and/or net with previous cash flows. 3. More secure. One has a check not only on the payment address (which already has one with https:// in the web shop scenario it is currently able support) but not on the refund. On 28.03.2014, at 15:01, Gavin Andresen wrote: > On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer 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] BIP 70 refund field
On 28.03.2014, at 17:34, Mike Hearn 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
On 28.03.2014, at 16:23, Mike Hearn wrote: > So I take it BOPShop won't be supporting BIP70 then? :( > Supporting BIP70 by BitPay or BopShop is a cake since it does no more then they did without it. I am not in opposition but see no reason to be enthusiastic about it. I will once the spec goes further than what was possible before. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 13:27, Mike Hearn wrote: > It is not more effort than an auto remembered call-in phone number. You > delete if you do not care. The difference however is that it would be a clean > protocol for repeated payments in both directions for whatever reason, where > "refund" is and "payment" are not special compared to "1st installment", > "overpayed back" or "tip" or whatever extra charge arises later. > > I think that'd be too abstract. The purpose of the refund field is that so > if/when you receive a payment there, the wallet UI can do something > intelligent, like show you in your transactions list that a certain payment > was refunded using language the user will understand. If it's modelled at the > protocol level without that then it makes producing good UI's harder. What is too abstract in a contact list ? If the payment comes with a tag like refund the UI could display as such and if it comes with e.g. VAT then that. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 14:00, Mike Hearn wrote: > What is too abstract in a contact list ? If the payment comes with a tag like > refund the UI could display as such and if it comes with e.g. VAT then that. > > How is this any different? The tag in this case is the address and the > payment is being delivered by the block chain (direct submission for > user->merchant is easier than merchant->user) so we can't stuff extra data > anywhere else. Then the UI knows it was a refund payment and not for anything > else. > The difference is the concept of setting up a channel that allows both parties to create valid addresses of the other by exchanging some kind of master keys. The initial handshake with the protocol would agree on tags of individual address indexes if used. The wallets would have to observe those agreed inidices and evtl. extend range. Payments could go back and forth. Either party might delete the channel information and stop observing keys as soon as he does no longer expect a payment from the other. This would be an explicit operation, like deleting a contact. > I don't see the relevance of VAT here. It was an example label. I would not be suprised if with widespread use of payments some government would require VAT collected separately. It is just a guess and has no weight in my prior arguments. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 refund field
On 28.03.2014, at 12:46, Mike Hearn 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 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
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 wrote: > > On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach > 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
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 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] New BIP32 structure
I think not all alts (will) have magic numbers, at least not those defined e.g. with colored coins on top of an other chain. Also note that the index should have MSB cleared as it would otherwise indicate private derivation. Regards, Tamas Blummer http://bitsofproof.com On 27.03.2014, at 16:57, Allen Piscitello 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 wrote: > On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer 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] New BIP32 structure
We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof) at the Inside Bitcoin Conference in Berlin. I remember that there were different opinions on how to use a hierarchy and it did seem to me they could eventually be "standardized" for the retail customer but definitelly not for corporate use, where hierarchy will certainly map to organisational hierarchy or cost centres. A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and cetral directory is not needed. Regards, Tamas Blummer http://bitsofproof.com On 26.03.2014, at 21:49, Mike Hearn 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] moving the default display to mbtc
I think you want to misunderstand me Andreas. It is astonishing arrogance to define the units because we in Bitcoin are used to some wierd notation and ignore that the vast majority of population and financial software in existence does not have a notion of prices with more than two decimals. With 1 bit = 100 satoshi, we would solve this problem for good. Instead mBTC is a confusing step in-between. Tamas Blummer http://bitsofproof.com On 14.03.2014, at 16:02, Andreas Schildbach 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 > <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 >>> <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 >>>>>>> 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
Re: [Bitcoin-development] moving the default display to mbtc
you miss the point Andreas. It is not about the magnitude but about the form of a price. A number with no decimals or with two decimals is percieved as a price in some currency. A number with more than two decimals is just not percieved as a price but as a geeky something that you rather convert to local currency. Tamas Blummer Bits of Proof On 14.03.2014, at 15:49, Andreas Schildbach 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 >> 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 >>>>> 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 >>>> <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 >>>> <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. >>>>>>
Re: [Bitcoin-development] moving the default display to mbtc
You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach 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 >> <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 >><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 >><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 >>>_
Re: [Bitcoin-development] moving the default display to mbtc
BTW, its not like this would be the first time this was raised, instead the "ship left" while ignoring arguments. The idea of is up there for votes since March 2013 https://bitcointalk.org/index.php?topic=149150.0 and received the most votes. I remembered this last time on this list here: http://sourceforge.net/p/bitcoin/mailman/message/31640769/ Regards, Tamas Blummer Founder, CEO Bits of Proof http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 13.03.2014, at 17:14, Alan Reiner 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
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] On OP_RETURN in upcoming 0.9
It costs at least 5430 satoshis to create an output at the moment. Is the same spam limit applied if the script is OP_RETURN? If not, I would be concerned od opening a cheap spam. Tamas Blummer On Mon, Feb 24, 2014 at 11:39 AM, Wladimir 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=126839071&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039: Final call
> At least Trezor and bitcoinj (Multibit) seems to be going in this way, > which is 100% of clients which expressed interest in bip39 :-). > > slush The the current spec with TREZOR's wordlist is also implemented by Bits of Proof https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/wallet/BIP39.java and deployed in two projects, one being btc1k also open sourced at our github. Regards, Tamás Blummer http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
Hi Jeff, such a vote is up there since March: https://bitcointalk.org/index.php?topic=149150.0 Votes are in favor of it. Advantages are obvious: 1. having satoshi as 1/100 of the main unit is familiar to people like USD and cent 2. All existing financial software can deal/store big numbers but typically only 2 decimals. 3. Split could be linked with the introduction of the ISO code in one step. Lets get it finally done. On Thu, 14 Nov 2013 19:05:06 -0500 Jeff Garzik wrote: > would suggest posting on all possible forums "proposal: switch to >uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion >is generated. If the support is broad, it will be plain from the >responses if there is a consensus. Perhaps everyone will agree it is >the best course, and we can make an easy change. > >But we need less "core dev fiat" not more :) > >-- >Jeff Garzik >Senior Software Engineer and open source evangelist >BitPay, Inc. https://bitpay.com/ Regards, Tamás Blummer Founder, CEO http://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
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=60135991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
