<unnamed>

Public Key

npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zm

Profile Code

nprofile1qqsd4ng0fp9eh40xjuz0uezjml4sqzkqr67rdnh306e7nw5kjmsnq8gpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg60f8wx

Publishing to

relay.primal.net

Last Notes

2023-06-07 17:25:41 CEST

- reply

📅 Original date posted:2014-09-12
📝 Original message:> What hash function would you recommend?
Due to the properties of hash functions, you can just take the first x
bits of a SHA256 sum and they're pretty much as good as an equally
secure hash function of that length. In fact SHA512/224 and SHA512/256
are defined in that way (Plus different initial values because you
might as well do that when defining a standard).
On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> On 09/12/2014 03:49 PM, Mike Hearn wrote:
>
>> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
>> here is that a MITM intercepts the payment request, which will be
>> typically requested just seconds after the QR code is vended. 80 bits of
>> entropy would still be a lot and take a long time to brute force, whilst
>> keeping QR codes more compact, which impacts scannability.
>
> To put that into perspective, here is how a bitcoin: URI would look like:
> bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE&r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest
> (obviously for real-world usage you would optimize the "r" parameter)
>
> I looked at the list in this doc to evaluate what's easily available:
> https://code.google.com/p/guava-libraries/wiki/HashingExplained
>
> I thought SHA1 has a bad reputation these days, and we don't save much
> by using it. I don't know anything about Murmur. MD5 is clearly broken.
> What hash function would you recommend?
>
>> (2) This should *not* be necessary in the common HTTPS context.
>
> It is. People can't check names. People don't want to check names.
> People can't get certificates for lots of reasons. X.509 is centralized.
> X.509 has had serious security issues in the past. And shit continues to
> happen.
>
> To sum up, X.509 can't replace the trust anchor that is established by
> scanning a QR code or tapping two devices together.
>
>> (3) This can be useful in the Bluetooth context, but then again, we
>> could also do things a different way by signing with the key in the
>> first part of the URI, thus avoiding the need for a hash.
>
> Sure. But signing is harder than just calculating a hash.
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:25:41 CEST

- reply

📅 Original date posted:2014-09-12
📝 Original message:Specifically relevant here:
http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits.
If you're going to truncate though, why not just leave the amount of
bits up the the person generating the QR code? The client simply takes
the hash prefix (any length up to full 256-bits) and makes sure it's a
strict prefix of the actual hash of the payment request.
That way we leave up to implementers to experiment with different
lengths and figure out what the optimum is (which could depend on the
security/convenience tradeoff of that particular transaction, as in
more bits for large payments).
On Fri, Sep 12, 2014 at 11:25 AM, Christophe Biocca
<christophe.biocca at gmail.com> wrote:
>> What hash function would you recommend?
>
> Due to the properties of hash functions, you can just take the first x
> bits of a SHA256 sum and they're pretty much as good as an equally
> secure hash function of that length. In fact SHA512/224 and SHA512/256
> are defined in that way (Plus different initial values because you
> might as well do that when defining a standard).
>
> On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach
> <andreas at schildbach.de> wrote:
>> On 09/12/2014 03:49 PM, Mike Hearn wrote:
>>
>>> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
>>> here is that a MITM intercepts the payment request, which will be
>>> typically requested just seconds after the QR code is vended. 80 bits of
>>> entropy would still be a lot and take a long time to brute force, whilst
>>> keeping QR codes more compact, which impacts scannability.
>>
>> To put that into perspective, here is how a bitcoin: URI would look like:
>> bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE&r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest
>> (obviously for real-world usage you would optimize the "r" parameter)
>>
>> I looked at the list in this doc to evaluate what's easily available:
>> https://code.google.com/p/guava-libraries/wiki/HashingExplained
>>
>> I thought SHA1 has a bad reputation these days, and we don't save much
>> by using it. I don't know anything about Murmur. MD5 is clearly broken.
>> What hash function would you recommend?
>>
>>> (2) This should *not* be necessary in the common HTTPS context.
>>
>> It is. People can't check names. People don't want to check names.
>> People can't get certificates for lots of reasons. X.509 is centralized.
>> X.509 has had serious security issues in the past. And shit continues to
>> happen.
>>
>> To sum up, X.509 can't replace the trust anchor that is established by
>> scanning a QR code or tapping two devices together.
>>
>>> (3) This can be useful in the Bluetooth context, but then again, we
>>> could also do things a different way by signing with the key in the
>>> first part of the URI, thus avoiding the need for a hash.
>>
>> Sure. But signing is harder than just calculating a hash.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:23:00 CEST

- reply

📅 Original date posted:2014-06-17
📝 Original message:https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
of the pooling-centralization problems. Unfortunately, it is opt-in,
and GHash.io doesn't support it.
Also most miners don't care and don't do the work to set it up. To do
transaction inclusion themselves, they'd need to run a full node,
which is a bit more work and resources than just pointing hashpower at
a stratum server.
If you figure out a way to make GBT widely used (>50% hashpower), kudos to you.
On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez <rme at i-rme.es> wrote:
> First of all I apologice due to the possible mistakes in my writing below, I
> am not a Bitcoin developer but I have some knowledge about it.
>
> ----
>
> We all know the recent news, Ghash pool controlling 51% of the hashrate.
> While some consider it a threat others think that is not harmful.
>
> The thing is that we have to do something to stop this from happening again.
>
> My proposal is to start thinking about miners that join a pool like
> independent miners and not slave miners, this includes creating a new mining
> protocol that does not rely on the pool sending the list of transactions to
> include in a block. Each individual miner has to collect transactions by his
> own and mine that, this can be achieved by running a full node or by running
> a SPV like node that ask other nodes for transactions.
>
> Once this protocol is developed and standarised we as a community could
> require all pools to use it (because its better, because is more
> trustless...), not by imposing it but by recommending it.
>
> Pool owners could send some instructions using this protocol to the miner
> about how many transactions to include per block (some pools want small
> blocks), how many 0 fee transactions to include, how much is the minimum fee
> per Kb to include transactions and some info about the Coinbase field in the
> block.
>
> This way is impossible to perform some of the possible 51% attacks:
>
> A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV
> or full node that has checkpoints and ask other peers about the length of
> the chain)
> A pool owner can't perform double spends or reverse transactions (pool
> clients know all the transactions relayed to the network, they know if they
> are already included on a block)
> A pool owner cant decide which transactions not to include (but they can
> configure the minimum fee).
> A pool owner cant get all the rewards by avoiding other pools from mining
> blocks (Because the pool client knows the last block independently that is
> from his pool or other).
>
>
> The only thing that a 51% pool owner can do is to shut down his pool and
> drop the hashrate by 51% because he does not control the miners.
>
> If the pool owner owns all the hardware in the pool my proposal is not
> valid, if the pool clients dont use this protocol my proposal is not valid.
>
>
> I want to know if this is possible or its been developed or there is already
> a working protocol that works like this, also I want to read other people's
> ways to address this threat, thanks for reading.
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:20:36 CEST

- 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:53 CEST

- reply

📅 Original date posted:2014-04-24
📝 Original message:Actually Peter, coinbase confiscations are a much worse mechanism for
enforcement of widespread censorship rules than simple orphaning. They
lose their power when the transaction miners are punished for can
build up over time without losing their usefulness:
Assume a world where 75% of the hashpower is coerced into
stealing/burning the coinbases of miners who allow transactions to and
from a particular set of addresses (the actual rule isn't that
important). Then the following would be a rational behaviour from the
remaining 25%:
- Mine according to the enforced rules most of the time.
- Accept banned transactions paying you with an output (no real
miners' fees) and keep them in an ever-accumulating pool.
- When there's so much of those to make it worth your while, mine a
block filled with them.
If miners don't orphan your block, you made money. They can't
retaliate further, because you can publish the block anonymously, not
tying it to your previous identity. Hell, some of the 75% might be
able to do the same right under the authorities' noses (it would be
really hard to spot by an external observer).
Note that I, banned user, can submit to all these non-enforcing miners
at once (with a different fee txout for each). I get a severe
degradation of service, especially if I'm part of an extremely small
minority, but ultimately as long as a single miner can accumulate
enough transactions with enough fees, I'll eventually get through.
Of course, in such a dystopian future, orphaning would be the
enforcement mechanism. It would be stupid to rely on coinbase
reallocation/burning to do this task when the existing tools work so
much better.
What's interesting is that this mechanism is especially tailored to
blocking time sensitive transactions (that need to be confirmed
now/soon, or are worthless), such that their total out-of-band fees
can't build up over time. Double spending is one such category. I'm at
a loss to come up with something else, but maybe someone has a good
example?
On Thu, Apr 24, 2014 at 10:09 AM, Mike Hearn <mike at plan99.net> wrote:
>> Like I said before, that leads to the obvious next step of
>> deleting/stealing their coinbases if they don't identify themselves.
>
>
> And as I said before, that's a huge leap. A majority of miners deciding
> double spending needs tougher enforcement doesn't imply they also think all
> miners should identify themselves. Those are unrelated things.
>
> This kind of totally unsupported "obvious next step" argument can be applied
> to any proposal in any walk of life. We developed SPV clients? The obvious
> next step is that miners have to stop being anonymous. We developed floating
> fees? The obvious next step is that miners have to stop being anonymous. The
> prior arguments sound absurd exactly because they're not obvious or even
> logical - same as this.
>
>
>
> ------------------------------------------------------------------------------
> 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:38 CEST

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

- 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:27 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:Just a few issues with the idea as it currently stands:
1. This provides a very strong incentive to always vote for
reallocating a block if it isn't yours, regardless of whether it's bad
or not (there's a positive expected return to voting to reallocate
coinbases from other miners). The incentive is bigger the more hash
power you have. You can partially address this by:
a) Requiring supermajorities
b) Requiring a vote to include proof of a double spend (that's not
a very strong safeguard, since anyone can create them after the fact
if one of their own transactions has been included).
c) Burning, rather than reallocating, the coins. Miners' immediate
incentive to attack honest pools is much reduced.
2. BitUndo gets paid using additional txouts in the double-spend
transaction, no by miner's fees. This means that the coinbase
transaction will represent a smaller and smaller share of their
revenues over time (however if the total honest transaction fees they
get in their block are high enough, the risk of losing those might
still be enough).
On Wed, Apr 23, 2014 at 3:55 AM, Mike Hearn <mike at plan99.net> wrote:
> Lately someone launched Finney attacks as a service (BitUndo). As a reminder
> for newcomers, Finney attacks are where a miner secretly works on a block
> containing a double spend. When they eventually find a block, they run to
> the merchant and pay, then broadcast the block. In a simpler variant of this
> attack you make purchases as normal with a modified wallet that always
> submits a double spend to the service, and then N% of the time where N is
> the percentage of overall hash power the dishonest miners have, you get your
> money back minus their fee.
>
> N does not need to be very high to render Bitcoin much less useful. Real
> time transactions are very important. Although I never expected it when I
> first started using Bitcoin, nowadays most of my purchases with it are for
> food and drink. If Bitcoin could not support such purchases, I would use it
> much less.
> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants win
> about 40% of chargeback disputes. So if N was only, say, 5%, and there was a
> large enough population of users who were systematically trying to defraud
> merchants, we'd already be having worse security than magstripe credit
> cards. EMV transactions have loss rates in the noise, so for merchants who
> take those Bitcoin would be dramatically less secure.
>
> The idea of discouraging blocks that perform Finney attacks by having honest
> miners refuse to build on them has been proposed. But it has a couple of
> problems:
>
> It's hard to automatically detect Finney attacks. Looking for blocks that
> contain unseen transactions that override the mempool doesn't work - the
> dishonest users could broadcast all their double spends once a Finney block
> was found and then broadcast the block immediately afterwards, thus making
> the block look like any other would in the presence of double spends.
>
> If they could be automatically identified, it possibly could be converted
> into a DoS on the network by broadcasting double spends in such a way that
> the system races, and every miner produces a block that looks like a Finney
> attack to some of the others. The chain would stop advancing.
>
> Miners who want to vote "no" on a block take a big risk, they could be on
> the losing side of the fork and end up wasting their work.
>
> We can resolve these problems with a couple of tweaks:
>
> Dishonest blocks can be identified out of band, by having honest miners
> submit double spends against themselves to the service anonymously using a
> separate tool. When their own double spend appears they know the block is
> bad.
>
> Miners can vote to reallocate the coinbase value of bad blocks before they
> mature. If a majority of blocks leading up to maturity vote for
> reallocation, the value goes into a pot that subsequent blocks are allowed
> to claim for themselves. Thus there is no risk to voting "no" on a block,
> the work done by the Finney attacker is not wasted, and users do not have to
> suffer through huge reorgs.
>
> This may seem a radical suggestion, but I think it's much less radical than
> some of the others being thrown around.
>
> The above approach works as long as the majority of hashpower is honest,
> defined to mean, working to stop double spending. This is the same security
> property as described in the white paper, thus this introduces no new
> security assumptions. Note that assuming all miners are dishonest and are
> willing to double spend automatically resolves the Bitcoin experiment as a
> failure, because that would invalidate the entire theory upon which the
> system is built. That doesn't mean the assumption is wrong! It may be that
> an entirely unregulated market for double spending prevention cannot work
> and the participants eventually all end up trashing the commons - but the
> hope is that smart incentives can replace the traditional reliance on law
> and regulation to avoid this.
>
> The voting mechanism would only apply to coinbases, not arbitrary
> transactions, thus it cannot be used to steal arbitrary users bitcoins. A
> majority of miners can already reallocate coinbases by forking them out, but
> this wastes energy and work presenting a significant discouragement to vote
> unless you already know via some out of band mechanism that you have a solid
> majority. Placing votes into the coinbase scriptSig as is done with other
> things avoids that problem.
>
> The identification of Finney blocks relies on miners to take explicit
> action, like downloading and running a tool that submits votes via RPC. It
> can be expected that double spending services would try to identify and
> block the sentinel transactions, which is why it's better to have the code
> that fights this arms race be out of process and developed externally to
> Bitcoin Core itself, which should ultimately just enforce the new (forking)
> rule change.
>
>
>
> ------------------------------------------------------------------------------
> 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:18:53 CEST

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

2023-06-07 17:12:43 CEST

- reply

📅 Original date posted:2014-01-29
📝 Original message:> But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector...
If the only concern is to make scan-to-pay work without reliance on
SSL's PKI, it might be better to specify the payment protocol url
*and* the public key used for signing right in the qr code. The wallet
connects to the url, fetches the payment request (maybe over a secure
connection, maybe not, doesn't matter), and verifies the signature
matches the public key from the qr code.
Downsides compared to embedding the entire request:
Payee needs to host/serve requests somewhere online. This introduces
reliability and DoS concerns.
Payer needs an internet connection to fetch the request.
Advantages:
Serve variable payment requests from the same qr code (improving
recipient privacy).
Still no hard dependency on CAs. Even if both CA and DNS are
compromised by an attacker, the worst they can do is Denial of
Service.
Optionally use CAs so that the wallet can attach an identity to who
you're paying by QR code. This partly addresses the problem of the
waiter overwriting the QR code. A non-PKI transaction would simply
show "Unknown recipient".
Much smaller QR code (only overhead is the key parameter, and you
could use a boolean param + the "address as public key" hack Mike
mentionned, for only 4 characters of overhead).
No need for a backward-incompatible bitcoin: scheme
On Mon, Jan 27, 2014 at 3:34 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
>> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
>> <andreas at schildbach.de> wrote:
>>
>> > SCAN TO PAY
>> > For scan-to-pay, the current landscape looks different. I assume at
>> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>> > into a QR-code. Nevertheless, I tried to encode a payment request into
>> > the bitcoin URL. I used my existing work on encoding transactions into
>> > QR-codes. Steps to encode:
>>
>> Really interesting work. When using scan-to-pay, after the payer scans the
>> QR code with the protobuf PaymentRequest (not a URL to download the
>> PaymentRequest) are they using their own connectivity to submit the
>> Payment response?
>>
>> If we assume connectivity on the phone, might as well just get a URL from
>> the QR code and re-use existing infrastructure for serving that?
>
> My first thought was likewise. In the case where the phone needs
> Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?
>
> I'm assuming that every client will have to support this is any case,
> since it's effectively mandated by the BIP, so why add another mode of
> operation?
>
> However, PaymentRequest-over-QR-code does seem to me to have one
> rather attractive advantage: the authentication model is orders of
> magnitude simpler and more intuitive for a face-to-face transaction
> than anything else. You're saying "pay the coins to that thing over
> there displaying that QR code". Which, most of the time, is exactly
> what you want.
>
> In the web case, it's fine to ignore the case where the URL domain has
> been subverted (and an cert obtained by the attacker) because in that
> case you've lost before you even get to payments (MitM attacker shows
> you a modified web page with different payment details). But the
> face-to-face case isn't intrinsically dependent on SSL security, and
> it's nice not to introduce that attack vector...
>
> roy
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:12:22 CEST

- reply

📅 Original date posted:2014-01-20
📝 Original message:I remember the wordlist choice getting bikeshedded to death a month ago.
I would just include the wordlist as part of the standard (as a
recommendation) so that fully compliant implementations can correct a
user's typos regardless of the original generator.
Those who don't like it will have to deal with the compatibility
concerns themselves, or get an alternate wordlist approved as a BIP.
Odds are no one will go that route.
On Mon, Jan 20, 2014 at 5:35 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
>> On Mon, Jan 20, 2014 at 11:42 AM, slush <slush at centrum.cz> wrote:
>>
>> > Hi all,
>> >
>> > during recent months we've reconsidered all comments which we received
>> > from the community about our BIP39 proposal and we tried to meet all
>> > requirements for such standard. Specifically the proposal now doesn't
>> > require any specific wordlist, so every client can use its very own list of
>> > preferred words. Generated mnemonic can be then applied to any other
>> > BIP39-compatible client. Please follow current draft at
>> > https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
>>
>> So, because the [mnemonic]->[bip32 root] is just hashing, you've
>> effectively made your "mnemonic sentence" into a brainwallet? Since every
>> mnemonic sentence can now lead to a bip32 root, and only the client that
>> created the mnemonic can verify the mnemonic passes its checksum (assuming
>> all clients use different wordlists, the only client that can help you if
>> you fat-finger the sentence is the client that created it)?
>
> That issue is more than enough to get a NACK from me on making the
> current BIP39 draft a standard - I can easily see that leading to users
> losing a lot of money.
>
> Have any wallets implemented BIP39 this way already in released code?
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000009c3092c0b245722363df8b29cfbb86368f4f7303e655983a
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:09:46 CEST

- reply

📅 Original date posted:2013-11-18
📝 Original message:Beat me to it. My own implementation is here:
https://github.com/christophebiocca/bitcoin-network-simulator
Same basic principles, but I've been following the protocol message
structure as much as possible/Theoretical support for transaction
propagation (I really want to see zero-conf stuff, and whether it works).
Running a network of 1000 full nodes (with 100 miners) for a week of
simulated time (with a normal hashrate) and empty blocks (except for the
coinbase transaction) takes about 30-60 seconds.
Uses nodejs, with the ultimate goal of having a network/chain visualization
running in the browser (with the actual simulation running on a WebWorker
to keep things responsive).
On Sun, Nov 17, 2013 at 11:43 AM, Rafael Brune <mail at rbrune.de> wrote:
> Over the last days I spent some time working on a simple Bitcoin network
> simulator.
> It is a stochastic event-based continuous-time simulation of Bitcoin miners
> exchanging messages and building block chains. It simulates latency,
> bandwidth
> and also verification speed but it currently does not simulate
> propagation/inclusion
> of transactions and instead uses random block sizes.
>
> The simulator includes two examples, one for a 51% attack and the other is
> an
> implementation of selfish mining (pretty much 1:1 as described in the
> paper).
> With the random parameters I picked it seems like it pays off to mine
> selfish with
> >=30% of the hashing power - but take this with a huge grain of salt as
> this
> is with a very small network and randomly chosen parameters. And of course
> it
> is not a perfect replica of the real world network.
>
> Since this is based on my understanding of the Bitcoin network and
> protocol it
> would be great if others would take a look and help improve it.
>
> The project can be found on my github:
> https://github.com/rbrune/btcsim
>
> Regards,
> Rafael Brune
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131117/0e733ccf/attachment.html>