Christophe Biocca [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-11-06 to 2015-09-11
💬 Posted a total of 33 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 19:40:00

- reply

📅 Original date posted:2015-09-11
📝 Original message:> How do you know which of 2 blocks with the same height is "newer"?
>From the particular node's perspective. I'm aware there is no
possibility of consistent global ordering.
Dave's code is about switching blocks (instead of continuing on the
existing one), and, in that context, "old" means the first sibling the
node saw, and "new" is any subsequent block. I will disambiguate this
in the future, because I'm clearly confusing at least 1 person.
> I don't see how miners would benefit from running this policy so I would not expect them to run it in the long run (like the "first seen" spend conflict tx replacement policy).
There's always a default, and if miners don't have any overriding
reason to change, they'll likely stick to it. Which is why Dave
started his statement with:
> Rather than (promising to, and when they don't actually, at least pretending to) use the first-seen block
Clearly recognizing that any changed logic is non-binding.
On 11 September 2015 at 14:37, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
> wrote:
>>
>> It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>
> I thought he was proposing a new consesnsus rule. I see, this would be just
> a policy validation that everybody would be free to ignore (like the "first
> seen" spend conflict tx replacement policy).
>
> I don't see how miners would benefit from running this policy so I would not
> expect them to run it in the long run (like the "first seen" spend conflict
> tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running that
> policy themselves.
> They will still have to keep waiting some block confirmation to
> exponentially reduce the chances of a successful double-spend attack with
> each new confirmation (as explained in the bitcoin white paper).
>
>> Mind you, that risk doesn't apply if we prefer non-empty blocks to
>> empty blocks and leave it at that, or only switch if the new block
>> doesn't double spend transactions in the old one, so it's a fixable
>> issue.
>
> How do you know which of 2 blocks with the same height is "newer"?
>
>> On 11 September 2015 at 12:32, Jorge Timón
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> Rather than (promising to, and when they don't actually, at least
>> >> pretending to) use the first-seen block, I propose that a more
>> >> sophisticated
>> >> method of choosing which of two block solutions to accept.
>> >
>> > There's already a criterion to chose: the one with more work (in valid
>> > blocks) on top of it.
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >

2023-06-07 17:25:20

- reply

📅 Original date posted:2014-08-19
📝 Original message:If your threat model is passive listeners, it seems to me that simply
establishing a symmetric key for each connection at handshake time
using diffie-hellman is all you need. No public private crypto needed
at all.
The whole thing seems like a bit of security theater unfortunately.
The kind of attacker that can pull off widespread passive listening is
probably able and willing to do active MITM. It's not a huge
incremental cost.
Instead, those users that do have a need for security should probably
connect to the network using Tor or I2P, which can give much better
security guarantees than anything being discussed here.
On Tue, Aug 19, 2014 at 12:58 PM, Angel Leon <gubatron at gmail.com> wrote:
> "
> I suggest that Bitcoin Core should generate a public/private key pair and
> share the public one with peers."
>
> I've not read the p2p protocol of Bitcoin core, but I suppose the initial
> handshake between 2 peers would be the ideal place to exchange a public
> keys.
>
> would it make sense to generate a new random pair of keys per each peer you
> connect to?
> then each subsequent message to every peer gets encrypted differently,
> keeping each conversation isolated from each other encryption-speaking.
>
> These keys would have nothing to do with your wallet, they're just to
> encrypt any further communication between peers post-handshake. Would that
> be of any use to "This could provide privacy and integrity but not
> autentication."?
>
> http://twitter.com/gubatron
>
>
> On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>>
>> On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
>> <justusranvier at riseup.net> wrote:
>> > If that's not acceptable, even using TLS with self-signed certificates
>> > would be an improvement.
>>
>> TLS is a huge complex attack surface, any use of it requires an
>> additional dependency with a large amount of difficult to audit code.
>> TLS is trivially DOS attacked and every major/widely used TLS
>> implementation has had multiple memory disclosure or remote execution
>> vulnerabilities even in just the last several years.
>>
>> We've dodged several emergency scale vulnerabilities by not having TLS.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:20:36

- reply

📅 Original date posted:2014-05-03
📝 Original message: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 <voisine at gmail.com> wrote:
> I have to agree with Mike. Human language is surprisingly tolerant of
> overloading and inference from context. Neurotypical people have no
> problem with it and perceive a software engineer's aversion to it as
> being pedantic and strange. Note that "bits" was a term for a unit of
> money long before the invention of digital computers.
>
> Aaron
>
> There's no trick to being a humorist when you have the whole
> government working for you -- Will Rodgers
>
>
> On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr <gojomo at gmail.com> wrote:
>> [resend - apologies if duplicate]
>>
>> Microbitcoin is a good-sized unit, workable for everyday transaction
>> values, with room-to-grow, and a nice relationship to satoshis as 'cents'.
>>
>> But "bits" has problems as a unit name.
>>
>> "Bits" will be especially problematic whenever people try to graduate
>> from informal use to understanding the system internals - that is, when
>> the real "bits" of key sizes, hash sizes, and storage/bandwidth needs
>> become important. The "bit" as "binary digit" was important enough that
>> Satoshi named the system after it; that homage gets lost if the word is
>> muddied with a new retconned meaning that's quite different.
>>
>> Some examples of possible problems:
>>
>> * If "bit" equals "100 satoshis", then the natural-language unpacking of
>> "bit-coin" is "100 satoshi coin", which runs against all prior usage.
>>
>> * If people are informed that a "256-bit private key" is what ultimately
>> controls their balances, it could prompt confusion like, "if each key
>> has 256-bits, will I need 40 keys to hold 10,000.00 bits?"
>>
>> * When people learn that there are 8 bits to a byte, they may think,
>> "OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes".
>>
>> * When people naturally extend "bit" into "kilobits" to mean "1000
>> bits", then the new coinage "kilobits" will mean the exact same amount
>> (100,000 satoshi) as many have already been calling "millibits".
>>
>> I believe it'd be best to pick a new made-up single-syllable word as a
>> synonym for "microbitcoin", and I've laid out the case for "zib" as that
>> word at <http://zibcoin.org>.
>>
>> 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ'
>> (Z-with-stroke), that remains distinctive even if it loses its stroke or
>> gets case-reversed. (Comparatively, all 'b'-derived symbols for
>> data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts
>> where subtleties of casing/stroking are lost.)
>>
>> (There's summary of more problems with "bit" in the zibcoin.org FAQ at:
>> <http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins>.)
>>
>> - Gordon
>>
>> On 5/1/14, 3:35 PM, Aaron Voisine wrote:
>>> I'm also a big fan of standardizing on microBTC as the standard unit.
>>> I didn't like the name "bits" at first, but the more I think about it,
>>> the more I like it. The main thing going for it is the fact that it's
>>> part of the name bitcoin. If Bitcoin is the protocol and network, bits
>>> are an obvious choice for the currency unit.
>>>
>>> I would like to propose using Unicode character U+0180, lowercase b
>>> with stroke, as the symbol to represent the microBTC denomination,
>>> whether we call bits or something else:
>>> http://www.fileformat.info/info/unicode/char/0180/index.htm
>>>
>>> Another candidate is Unicode character U+2422, the blank symbol, but I
>>> prefer stroke b.
>>> http://www.fileformat.info/info/unicode/char/2422/index.htm
>>>
>>> Aaron
>>>
>>> There's no trick to being a humorist when you have the whole
>>> government working for you -- Will Rodgers
>>>
>>>> On Apr 21, 2014 5:41 AM, "Pieter Wuille" <pieter.wuille at gm...> wrote:
>>>>
>>>>> On Apr 21, 2014 3:37 AM, "Un Ix" <slashdevnull at ...> 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
>>>
>>> ------------------------------------------------------------------------------
>>> "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 at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>> ------------------------------------------------------------------------------
>> "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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> "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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:19:38

- reply

📅 Original date posted:2014-04-26
📝 Original message:This seems like splitting hairs, no? A block isn't a guarantee (it can
get orphaned). And as a user of bitcoin (as opposed to a miner), this
change cannot affect any payment you ever receive.
Some of the interpretation is already different for coinbase UTXO's
(need a valid height, locked for 100 blocks). Anyone expecting them to
behave like any other UTXO will get bitten by one of those subtleties
(MtGox's withdrawals had issues with exactly this, IIRC).
On Sat, Apr 26, 2014 at 8:15 AM, Gareth Williams <gacrux at gmail.com> wrote:
> On 26/04/14 01:28, Mike Hearn wrote:
>> When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>>
>> sure that money is yours - but only because the rules for interpreting
>> data in the blockchain are publicly documented and (hopefully)
>> immutable. If they're mutable then the PoW alone gives me no confidence
>> that the money is really mine, and we're left with a much less useful
>> system. This should be more sacred than the 21m limit.
>>
>>
>> Well, I think we should avoid the term "sacred" - nothing is sacred
>> because we're not building a religion here, we're engineering a tool.
>
> Are you sure there isn't room for just a touch of "religion"? :) As you
> state below, all that protects my money from confiscation is strong
> group consensus that it's mine - "a social rule, not a mathematical one."
>
> Everything ultimately balances on that. People being a little bit
> "religious" about following the protocol faithfully are the linchpin of
> Bitcoin security, not PoW.
>
>
>> Consider a world in which 1 satoshi is too valuable to represent some
>> kinds of transactions, so those transactions stop happening even though
>> we all agree they're useful. The obvious solution is to change the rules
>> so there can be 210 million coins and 10x everyones UTXOs at some
>> pre-agreed flag day. We probably wouldn't phrase it like that, it's
>> easier for people to imagine what's happening if it's phrased as "adding
>> more places after the decimal point" or something, but at the protocol
>> level coins are represented using integers, so it'd have to be
>> implemented as a multiply.
>
> Agree.
>
>
>> Would this be a violation of the social contract? A violation of all
>> that is sacred? I don't think so, it'd just be sensible engineering and
>> there'd be strong consensus for that exactly because 21 million /is/ so
>> arbitrary. If all balances and prices multiply 100-fold overnight, no
>> wealth is reallocated which would be the /actual/ violation of the
>> social contract: we just get more resolution for setting prices.
>
> Wholeheartedly agree. "21 million" is just shorthand for the
> preservation of artificial scarcity. No rational person could argue that
> what you described violates the social contract.
>
> I do see what you're driving at - that there exists a situation where it
> would be justified to change the interpretation of data in existing blocks.
>
> But, please consider: if I controlled a single UTXO worth 1% of the
> total money supply before your change, the network would still recognise
> that I control a single UTXO worth 1% of the total money supply after
> your change. So you haven't really changed the interpretation of
> existing blocks at all there. It's just semantics :)
>
> Contrast this with invalidating a coinbase before maturity, which
> clearly has a very real impact. At the point the vote passes, you're ***
> sidestepping the PoW mechanism and rewriting the meaning of an existing,
> validated block ***.
>
>
>> So. The thing that protects your money from confiscation is not proof of
>> work. PoW is just a database synchronisation mechanism. The thing that
>> protects your money from confiscation is a strong group consensus that
>> theft is bad. But that's a social rule, not a mathematical rule.
>
> Agree. That's my whole point :)
>
> I recognise my security is in the hands of the users (the economic
> majority.) Tomorrow they could all decide to patch their nodes to
> reallocate my UTXOs, and there's not a damn thing I could do about it,
> PoW and private keys notwithstanding. I must simply trust that they will
> not do this.
>
> So we can have:
> 1. "Neutral Bitcoin", where everyone is committed to prevention of theft
> by following a simple set of mathematical rules which treat all
> validated blocks as equal.
> Or:
> 2. "Political Bitcoin", where everyone is committed to prevention of
> theft based on human judgements, and the contents of some validated
> blocks are more equal than others.
>
> I recognise that the latter allows for a lot of flexibility in combating
> fraud, but with (substantial) due respect, it isn't Bitcoin.
>
> -Gareth
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:19:33

- reply

📅 Original date posted:2014-04-23
📝 Original message:It's not necessary that this "coinbase retribution" be either
profitable or risk-free for this scheme to work. I think we should
separate out the different layers of the proposal:
1. Attacking the coinbase instead of orphaning allows for 100 blocks'
time for a consensus to be reached, rather than 10 minutes. This
allows for human verification/intervention if needed (orphaning
decisions would almost always need to be automated, due to the short
timeframe). This is a useful insight, and I don't think it's been
brought up before.
2. The original specification of how it's done (redistribution, no
cost to voting) does seem exploitable. This can be fixed by reducing
the incentive (burning instead of redistributing) and/or adding a risk
to the orphaning attempts (a vote that fails destroys X bitcoins'
worth from each voting block's own coinbase). The incentives can be
tailored to mirror those of orphaning a block, to reduce the risk of
abuse. Then the only difference from orphaning are 1) More limited
rewriting of history (only the coinbase, vs all transactions in the
block), and 2) More time to coordinate a response.
3. This proposal may be used for things other than punishing
double-spend pools. In fact it might be used to punish miners for
doing anything a significant percentage of hashpower dislikes (large
OP_RETURNs, large blocks, gambling transactions, transactions banned
by a government). But we can make the threshold higher than 51%, so
that this doesn't turn into a significant risk (if 75% of hashpower is
willing to enforce a rule, we're already likely to see it enforced
through orphaning).
On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>
>>
>> And it still would. Non-collusive miners cast votes based on the outcome
>> of their own attempts to double spend.
>
>
> Individually rational strategy is to vote for coinbase reallocation on every
> block.
>
> Yes, in that case nobody will get reward. It is similar to prisoner's
> dilemma: equilibrium has worst pay-off.
> In practice that would mean that simple game-theoretic models are no longer
> applicable, as they lead to absurd results.
>
>>
>> I'm using it in the same sense Satoshi used it. Honest miners work to
>> prevent double spends. That's the entire justification for their existence.
>> Miners that are deliberately trying to double spend are worse than useless.
>
>
> Miners work to get rewards.
> It absolutely doesn't matter whether they are deliberately trying to
> double-spend or not: they won't be able to double-spend without a collusion.
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:19:02

- reply

📅 Original date posted:2014-04-20
📝 Original message:Culturally neutral? "bit" in French phonetically collides with slang
for phallus ("bitte", with a silent "e"). Apparently it means "louse"
in Turkish as well.
Not that this really would be avoidable with any short word (all the
short possible words are usually taken), but it's not neutral.
On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin at olivere.de> wrote:
> Hello,
>
> just my two 'cents':
>
> Terms arises by itself. Just as most people speak of coins when they
> mean bitcoins. I do not see that bitcoin is currently in common use
> except for speculation. Therefore no term for smaller units has
> established yet. No problem in my eyes. Time will tell.
>
> - oliver
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:18:53

- reply

📅 Original date posted:2014-04-20
📝 Original message:If you absolutely want a name for some small unit (which may be
valuable, not knocking that part of the idea), please use anything
other than "bits", which is already a massively overloaded term that
will confuse the hell out of people:
Harddrive costs measured in "bits per gigabyte"?
An itunes movie download that costs 200,000 bits and takes 804.2
megabytes of space?
Or a 10-megabit internet connection costing 10,000,000 bits per month?
It's especially bad given that bitcoin will likely be adopted first
for online use, where the competing (and more recognized) meaning of
"bit" is most prevalent.
Not to mention the overlap within bitcoin itself, with people already
using "millibits" in conversation as a shorthand for mBTC. Hence one
new "bit" is exactly 1/1000 of the old "millibit".
Make something up if you have to, or just use satoshis.
On Sun, Apr 20, 2014 at 10:28 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> People on this list are mostly engineers who have no problem dealing with
> magnitudes and have rather limited empathy for people who have a problem
> with them.
> They also tend to think, that because they invented money 2.0 they would not
> need to care of finance’s or people’s current customs.
>
> The importance of their decisions in these questions will fade as people
> already use wallets other than the core.
>
> Bring this particular discussion elsewhere, to the wallet developer.
>
> BTW the topic was discussed here several times, you have my support and Jeff
> Garzik’s.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com> wrote:
>
> The average person is not going to be confident that the prefix they
> are using is the correct one,
>
>
> The use of any 'prefix' is one of choice and entirely unnecessary, and there
> are already established 'divisions' in u/mBTC for those that feel they need
> to use such things.
>
> people WILL send 1000x more or less than
> intended if we go down this road,
>
>
> Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3
> dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not
> once in 20 years has anyone ever 'sent' more or less than intended - oh,
> they've 'intended' to underpay just fine, but never *unintended*.
>
> I propose that users are offered a preference to denominate the
> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
> equals one million bits (bits) and one bit equals 100 satoshis.
>
>
> I propose that for people unable to understand what a bitcoin is, they can
> just use satoshi's and drop this entire proposal.
>
> Rob
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>