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
Des
hink 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 u
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 descripti
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
mes 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 us
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 Wo
gher 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.
T
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
.
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
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 G
sting
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
---
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
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 ins
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
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
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
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
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:
>> Kn
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.
in’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:
> L
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
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
ereby 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,
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
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
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
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
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
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
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.cl
I think there are three typical uses:
1. Building consensus on the block chain. This is what the core is for.
2. Single user wallets. This is where SPV alone is good.
3. Services e.g. exchange, payment processor This is where core + indexing
server talking SPV to core is the right choice
Re
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-Bro
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
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-decima
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
>
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
e 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
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. Rememb
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 d
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
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
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.
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 fract
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 B
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
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 th
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
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
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,
. 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
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
.
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,
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
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
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
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 gett
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
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
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 requeste
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
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
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 the
.
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 a
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
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
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
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
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
.
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 transacti
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 bi
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 initiate
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 p
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 sub
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 compa
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
an 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
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
gards,
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 tha
rting
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
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
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, Ta
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
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
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
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 bei
ean 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, 20
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
> w
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
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
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
.
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
> lobbyi
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 famili
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 q
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
--
L
ould 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 P
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
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 k
> 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/j
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 bu
.
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
1 - 100 of 107 matches
Mail list logo
