Mike Koss [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-04-03 to 2012-12-05
💬 Posted a total of 7 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 10:46:48

- reply

📅 Original date posted:2012-12-05
📝 Original message:I've implemented an alternative to the BIP 32 proposal. I wanted a system
based on a hierarchical string representation (rather than hierarchy of
integers as BIP 32 proposes). For example I name keys like this:
[hd1.75491111].store.1. 1D7GM5dkUtxvGeWgn7SYtanBuyj1MD1EZy
[hd1.75491111].store.2. 1QAqDbzpNKViGSjVe1XmnGbmZtvz5hM7t1
[hd1.75491111].store.3. 14XkSN92QLGeorYPpoVbG87DQhowEx3mFn
[hd1.75491111].store.4. 1JLcGdod6Wm33rMZuZZUmAEE6osLhM4QMn
First draft of proposal:
https://gist.github.com/4211704
I envision using this in services, so I've not done any work to recommend
how the keys would be represented directly in the client (I just map from a
seed value and
a hierarchy string in order to deterministic ally derive ECDSA public and
private keys).
I'm happy to release my source code for this (Python). But I'd first like
to get feedback about any security concerns with my scheme (I note that I
don't introduce the enlarged
key space that BIP 32 does with its "chain code" - I'm wondering if that
represents a weakness of my scheme vs. BIP 32).
On Mon, Dec 3, 2012 at 12:44 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Mon, Dec 03, 2012 at 06:48:34AM -0800, Amir Taaki wrote:
> > ok, also what is the reasoning behind serialising points using a
> compressed
> > format before going into the hash function? I'm looking at the
> sec1-v2.pdf
> > and the compression format is a little confusing.
>
> I don't think there is a compelling reason to encourage uncompressed public
> keys anymore on the network. They take more space in the block chain for no
> additional value whatsoever. Software may of course continue supporting
> uncompressed keys if they wish to provide compatibility, but for a new
> standard, I think it makes sense to standardize on just compressed keys.
> And since that software thus needs to support the compressed encoding,
> there is no reason to use a different encoding inside the derivation scheme
> itself.
>
> Regarding the encoding itself, it is not hard: just 0x02 or 0x03 (depending
> on whether Y is even or odd) followed by the 32-byte encoding of X.
> Decoding
> is harder, but is never needed in the derivation. Software internally can
> use
> any representation (and it will), which in almost all circumstances stores
> both X and Y (and even more). Decoding compressed public keys is somewhat
> harder, as Y must be reconstructed (but the algorithm isn't hard) - this is
> only necessary when someone wants to import an extended public key though
> for
> watch-only wallets.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/9a5e0265/attachment.html>

2023-06-07 10:42:41

- reply

📅 Original date posted:2012-12-03
📝 Original message:The thing that bugged me most about the original spec was the sole reliance
on X.509 - glad to see you've made that optional. I think many people will
balk at deferring our identity trust to the existing CA's. I think it's a
fine bootstrap method, but I'd really like to see another option that
allows for out-of-band trust (based on ECDSA, probably).
It would also be really nice to migrate to textual representations of data
structures as opposed to binary ones. The most successful internet
standards are based on text, making them that much more accessible for
developers to deal with them. JSON would be my preferred candidate.
Why don't we sign the text representation of a (utf8) JSON, rather than
some complex encoding standard of JSON? That way the signatures are simple
- and you need only retain the original textual representation of a message
to validate the signature (as well as the decoded version, if you don't
want to alway re-parse the message when writing programs that use it).
On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> Spec updated: https://gist.github.com/4120476
>
> Changes are:
>
> Version numbers: a couple of people asked privately about adding
> version numbers to the messages. In general, Protocol Buffers don't
> need version numbers if later versions add only optional fields.
>
> And best-practice is to know what version of something you're
> expecting BEFORE you start parsing that something.
>
> So, if a bitcoin client is getting Invoice messages via email or from
> a web server, the version will be specified as part of the MIME type;
> for example:
> Content-Type: application/x-bitcoin-invoice; version=1
> The version= syntax is part of the MIME standard.
>
> Following that best-practice of knowing what you're parsing before you
> parse it, I added an invoice_version field to the SignedInvoice
> message. It is now:
>
> message SignedInvoice {
> required bytes pki_data = 1;
> required string pki_type = 2 [default = "x509"];
> required bytes serialized_invoice = 3;
> required uint32 invoice_version = 4 [default = 1];
> required bytes signature = 5;
> }
>
>
> Handling of receiptURI errors:
>
> Following discussion here, I changed the spec to say:
>
> "Clients may handle errors communicating with the receiptURI server
> however they like, but should assume that if they cannot communicate
> at all with the server then the Payment should either be retried later
> or immediately rejected."
>
> and under Receipt added:
>
> "The Bitcoin client must be prepared to handle the case of an evil
> merchant that returns accepted=false but broadcasts the transactions
> anyway."
>
>
> I also added a TODO "Test Vectors" section with base64-encoded
> examples of everything.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/62146299/attachment.html>

2023-06-07 10:18:27

- reply

📅 Original date posted:2012-06-21
📝 Original message:Are we just talking about pruning the spent transactions from an old block?
We already have a data structure that allows us to replace any un-needed
transaction by just it's hash - and possibly a whole sub-tree if we get
lucky in that the un-needed transaction all fall within a common node of
the merkle tree.
If a lite client only cares to retain a single transaction in a block (the
most common case) - it will only need O(log2(T)) merkle hashes plus the
transaction it cares about.
Does it really make sense to adopt a more complex data-structure than the
merkle tree for inclusing in the bticoin protocol? And we're not talking
about blocks with millions of transactions in them - I don't understand the
relevance of Order statistics for random access to a transaction given its
block.
On Tue, Jun 19, 2012 at 11:30 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> On 06/19/2012 02:18 PM, Mark Friedenbach wrote:
>
> On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner <etotheipi at gmail.com> wrote:
>
> If we were to use a raw trie structure, then we'd have all the above
>> issues solved: a trie has the same configuration no matter how elements
>> are inserted or deleted, and accesses to elements in the tree are
>> constant time -- O(1). There is no such thing as an unbalanced trie.
>> But overall space-efficiency is an issue.
>>
>> A PATRICIA tree/trie would be ideal, in my mind, as it also has a
>> completely deterministic structure, and is an order-of-magnitude more
>> space-efficient. Insert, delete and query times are still O(1).
>> However, it is not a trivial implementation. I have occasionally looked
>> for implementations, but not found any that were satisfactory.
>>
>
> No, a trie of any sort is dependent upon distribution of input data for
> balancing. As Peter Todd points out, a malicious actor could construct
> transaction or address hashes in such a way as to grow some segment of the
> trie in an unbalanced fashion. It's not much of an attack, but in principle
> exploitable under particular timing-sensitive circumstances.
>
> Self-balancing search trees (KVL, RB, 2-3-4, whatever) don't suffer from
> this problem.
>
> Mark
>
>
> I was using "unbalanced" to refer to "query time" (and also insert/delete
> time). If your trie nodes branch based on the next byte of your key hash,
> then the max depth of your trie is 32. Period. No one can do anything to
> ever make you do more than 32 hops to find/insert/delete your data. And
> if you're using a raw trie, you'll always use *exactly* 32 hops
> regardless of the distribution of the underlying data. Hence, the trie
> structure is deterministic (history-independent) and cannot become
> unbalanced in terms of access time.
>
> My first concern was that a malicious actor could linearize parts of the
> tree and cause access requests to take much longer than log(N) time. With
> the trie, that's not only impossible, you're actually accessing in O(1)
> time.
>
> However, you are right that disk space can be affected by a malicious
> actor. The more branching he can induce, the more branch nodes that are
> created to support branches with only one leaf.
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120621/84612184/attachment.html>

2023-06-07 10:14:15

- reply

📅 Original date posted:2012-06-15
📝 Original message:Grouping mempool transactions based on fees of the group seems
an unnecessary complexity; it makes it harder to predict if an isolated
transaction has enough "juice" to be included in the next Block.
Given your point about economic actors adapting to conditions, would it not
be simpler to use a individual "fee per byte" priority algorithm and let
transaction generators distribute their fees accordingly (and more
predictably)?
This simpler algorithm will prune arbitrary transactions sub-optimally, but
has the benefit of being more understandable and predictable from the point
of view of transaction generators.
On Fri, Jun 15, 2012 at 9:56 AM, Stefan Thomas <moon at justmoon.de> wrote:
> Thanks Mike for the writeup - I'm very sad to have missed the discussion
> on IRC since fee economics are probably my favorite topic, but I'll try
> to contribute to the email discussion instead.
>
> > (4) Making the block size limit float is better than picking a new
> > arbitrary threshold.
>
> Fees are a product of both real and artificial limits to transaction
> validation.
>
> The artificial limits like the block size limit are essentially putting
> a floor on prices by limiting supply beyond what it would otherwise be.
> E.g. the network could confirm more transactions theoretically, but the
> block size limit prevents it.
>
> The real limits are the bandwidth, computing and memory resources of
> participating nodes. For the sake of argument suppose a 1 TB block was
> released into the network right now and we'll also assume there was no
> block size limit of any kind. Many nodes would likely not be able to
> successfully download this block in under 10-30 minutes, so there is a
> very good chance that other miners will have generated two blocks before
> this block makes its way to them.
>
> What does this mean? The miner generating a 1 TB block knows this would
> happen. So in terms of economic self interest he will generate the
> largest possible block that he is still confident that other miners will
> accept and process. A miner who receives a block will also consider
> whether to build on it based on whether they think other miners will be
> able to download it. In other words, if I receive a large block I may
> decide not to mine on it, because I believe that the majority of mining
> power will not mine on it - because it is either too large for them to
> download or because their rules against large blocks reject it.
>
> It's important to understand that in practice economic actors tend to
> plan ahead. In other words, if there is no block size limit that doesn't
> mean that there will be constant forks and total chaos. Rather, no miner
> will ever want to have a block rejected due to size, there is plenty of
> incentive to be conservative with your limits. Even if there are forks,
> this simply means that miners have decided that they can make more money
> by including more transactions at the cost of the occasional dud.
>
> Therefore, from an economic perspective, we do not need a global block
> size limit of any kind. As "guardians of the network" the only thing we
> need to do is to let miners figure out what they wanna do.
>
> HOWEVER, the existing economic incentives won't manifest unless somebody
> translates them into code. We have to give our users (miners & endusers)
> the tools to create a genuine fee-based verification market.
>
> On the miner side: I would make the block size limit configurable with a
> relatively high default. If the default is too low few people will
> bother changing it, which means that it is not worth changing (because a
> majority uses the default anyway), which means even fewer people will
> change it and so on.
>
> The block size limit should also be a soft rather than a hard limit -
> here are some ideas for this:
>
> - The default limit for accepting blocks from others should always be
> significantly greater than the default limit for blocks that the client
> itself will generate.
>
> - There should be different size limits for side chains that are longer
> than the currently active chain. In other words, I might reject a block
> for being slightly too large, but if everyone else accepts it I should
> eventually accept it too, and my client should also consider
> automatically raising my size limit if this happens a lot.
>
> The rationale for the soft limit is to allow for gradual upward
> adjustment. It needs to be risky for individual miners to raise the size
> of their blocks to new heights, but ideally there won't be one solid
> wall for them to run into.
>
> On the user side: I would display the fee on the Send Coins dialog and
> allow users to choose a different fee per transaction. We also talked
> about adding some UI feedback where the client tries to estimate how
> long a transaction will take to confirm given a certain fee, based on
> recent information about what it observed from the network. If the fee
> can be changed on the Send Coins tab, then this could be a red, yellow,
> green visual indication whether the fee is sufficient, adequate or
> dangerously low.
>
> A criticism one might raise is: "The block size limit is not to protect
> miners, but to protect end users who may have less resources than miners
> and can't download gigantic block chains." - That's a viewpoint that is
> certainly valid. I believe that we will be able to do a lot just with
> efficiency improvements, pruning, compression and whatnot. But when it
> comes down to it, I'd prefer a large network with cheap
> microtransactions even if that means that consumer hardware can't
> operate as a standalone validating node anymore. Headers-only mode is
> already a much-requested feature anyway and there are many ways of
> improving the security of various header-only or lightweight protocols.
>
> (I just saw Greg's message advocating the opposite viewpoint, I'll
> respond to that as soon as I can.)
>
>
> > (1) Change the mining code to group transactions together with their
> > mempool dependencies and then calculate all fees as a group.
>
> +1 Very good change. This would allow miners to maximize their revenue
> and in doing so better represent the existing priorities that users
> express through fees.
>
>
> > There was discussion of some one-off changes to address the current
> > situation, namely de-ranking transactions that re-use addresses.
>
> Discouraging address reuse will not change the amount of transactions, I
> think we all agree on that. As for whether it improves the
> prioritization, I'm not sure. Use cases that we seek to discourage may
> simply switch to random addresses and I don't agree in and of itself
> this is a benefit (see item 4 below). Here are a few reasons one might
> be against this proposal:
>
> 1) Certain use cases like green addresses will be forced to become more
> complicated than they would otherwise need to be.
>
> 2) It will be harder to read information straight out of the block
> chain, for example right now we can pretty easily see how much volume is
> caused by Satoshi Dice, perhaps allowing us to make better decisions.
>
> 3) The address index that is used by block explorers and lightweight
> client servers will grow unnecessarily (an address -> tx index will be
> larger if the number of unique addresses increases given the same number
> of txs), so for people like myself who work on that type of software
> you're actually making our scalability equation slightly worse.
>
> 4) You're forcing people into privacy best practices which you think are
> good, but others may not subscribe to. For example I have absolutely
> zero interest in privacy, anyone who cares that I buy Bitcoins with my
> salary and spend them on paragliding is welcome to know about it.
> Frankly, if I cared about privacy I wouldn't be using Bitcoin. If other
> people want to use mixing services and randomize their addresses and
> communicate through Tor that's fine, but the client shouldn't force me
> to do those things if I don't want to by "deprioritizing" my transactions.
>
> 5) We may not like firstbits, but the fact remains that for now they are
> extremely popular, because they improve the user experience where we
> failed to do so. If you deprioritize transactions to reused addresses
> you'll for example deprioritize all/most of Girls Gone Bitcoin, which
> (again, like it or not) is one of the few practical, sustainable niches
> that Bitcoin has managed to carve out for itself so far.
>
>
> > Having senders/buyers pay no fees is psychologically desirable even
> > though we all understand that eventually, somebody, somewhere will be
> > paying fees to use Bitcoin
>
> Free is just an extreme form of cheap, so if we can make transactions
> very cheap (through efficiency and very large blocks) then it will be
> easier for charitable miners to include free transactions. In practice,
> my prediction is that free transactions on the open network will simply
> not be possible in the long run. Dirty hacks aside there is simply no
> way of distinguishing a spam transaction from a charity-worthy
> transaction. So the way I envision free transactions in the future is
> that there may be miners in partnership with wallet providers like
> BlockChain.info that let you submit feeless transactions straight to
> them based on maybe a captcha or some ads. (For the purist, the captcha
> challenge and response could be communicated across the bitcoin network,
> but I think we agree that such things should ideally take place
> out-of-band.)
>
> That way, the available charity of miners who wish to include feeless
> transactions would go to human users as opposed to the potentially
> infinite demand of auto-generated feeless transactions.
>
>
>
> On 6/15/2012 1:29 PM, Mike Hearn wrote:
> > I had to hit the sack last night as it was 2am CET, but I'd like to
> > sum up the discussion we had on IRC about scalability and SatoshiDice
> > in particular.
> >
> > I think we all agreed on the following:
> >
> > - Having senders/buyers pay no fees is psychologically desirable even
> > though we all understand that eventually, somebody, somewhere will be
> > paying fees to use Bitcoin
> >
> > - In the ideal world Bitcoin would scale perfectly and there would be
> > no need for there to be some "winners" and some "losers" when it comes
> > to confirmation time.
> >
> > There was discussion of some one-off changes to address the current
> > situation, namely de-ranking transactions that re-use addresses. Gavin
> > and myself were not keen on this idea, primarily because it just
> > avoids the real problem and Bitcoin already has a good way to
> > prioritize transactions via the fees mechanism itself. The real issue
> > is that SatoshiDice does indeed pay fees and generates a lot of
> > transactions, pushing more traditional traffic out due to artificial
> > throttles.
> >
> > The following set of proposals were discussed:
> >
> > (1) Change the mining code to group transactions together with their
> > mempool dependencies and then calculate all fees as a group. A tx with
> > a fee of 1 BTC that depends on 5 txns with zero fees would result in
> > all 6 transactions being considered to have a fee of 1BTC and
> > therefore become prioritized for inclusion. This allows a transition
> > to "receiver pays" model for fees. There are many advantages. One is
> > that it actually makes sense ... it's always the receiver who wants
> > confirmations because it's the receiver that fears double spends.
> > Senders never do. What's more, whilst Bitcoin is designed to operate
> > on a zero-trust model in the real world trust often exists and it can
> > be used to optimize by passing groups of transactions around with
> > their dependencies, until that group passes a trust boundary and gets
> > broadcast with a send-to-self tx to add fees. Another advantage is it
> > simplifies usage for end users who primarily buy rather than sell,
> > because it avoids the need to guess at fees, one of the most
> > problematic parts of Bitcoins design now.
> >
> > The disadvantages are that it can result in extra transactions that
> > exist only for adding fees, and it requires a more modern payment
> > protocol than the direct-IP protocol Satoshi designed.
> >
> > It would help address the current situation by avoiding angry users
> > who want to buy things, but don't know what fee to set and so their
> > transactions get stuck.
> >
> > (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
> > avoid paying excessive fees and queue-jumping. Guess that's on my
> > plate.
> >
> > (3) Scalability improvements seem like a no brainer to everyone, it's
> > just a case of how complicated they are.
> >
> > (4) Making the block size limit float is better than picking a new
> > arbitrary threshold.
> >
> > On the forums Matt stated that block chain pruning was a no-go because
> > "it makes bitcoin more centralized". I think we've thrashed this one
> > out sufficiently well by now that there should be a united opinion on
> > it. There are technical ways to implement it such that there is no
> > change of trust requirements. All the other issues (finding archival
> > nodes, etc) can be again addressed with sufficient programming.
> >
> > For the case of huge blocks slowing down end user syncing and wasting
> > their resources, SPV clients like MultiBit and Android Wallet already
> > exist and will get better with time. If Jeff implements the bloom
> > filtering p2p commands I'll make bitcoinj use them and that'll knock
> > out excessive bandwidth usage and parse overheads from end users who
> > are on these clients. At some point Bitcoin-Qt can have a dual mode,
> > but who knows when that'll get implemented.
> >
> > Does that all sound reasonable?
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120615/1bc049d6/attachment.html>

2023-06-07 10:11:44

- reply

📅 Original date posted:2012-06-04
📝 Original message:I don't understand how your proposal will work for decentralized pools -
can you explain it more concretely?
What would the new block header look like?
What is required for a share to to be earned?
What is required for a block to be valid (added to Block Chain)?
I don't think I understand what you mean by NextBlockCandidate. Perhaps a
concrete example using difficulty 1.7 million would be instructive.
On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> > As I understand the attack, the attacker gets compensated for the shares
> > they earn, but the pool will be denied any valid blocks found. The
> > attacker DOES NOT have access to the Bitcoins earned in the unreported
> > block (only the mining pool has access to the Coinbase address and
> > transactions in the block).
>
> With decentralized pools, the attacker does have access to the block, and
> can
> potentially submit it to the Bitcoin network directly bypassing the pool
> if it
> benefits them to do so.
>
> > So it's a zero-net-cost attack for the attacker (but no chance of making
> a
> > profit) to hurt the pool operator.
>
> Because of the above, there is a possibility an attacker can make a profit.
>
> > The only way to detect such an attack now is to look for "unlucky"
> miners;
> > at the current difficulty, you can't detect this cheat until many
> millions
> > of shares have been earned w/o a qualifying block. Since an attacker can
> > also create many fake identities, they can avoid detection indefinitely
> by
> > abandoning each account after a million earned shares.
>
> There are other modes of detection, but nobody has bothered to implement
> them
> since attackers can easily do a simple workaround in an arms race.
>
> > I don't understand your proposal for fixing this. You would have to come
> > up with a scheme where:
> >
> > - The miner can detect a qualifying hash to earn a share.
> > - Not be able to tell if the hash is for a valid block.
>
> With my proposal, miners can find shares, but won't know if it's a valid
> block
> until the subsequent block is also found (that subsequent block might not
> end
> up being a real block in the big picture).
>
> > The way I would do this is to have a secret part (not shared with the
> > miners) of a block that is part of the merkle hash, which is also used
> in a
> > secondary hash. Difficulty is then divide into two parts: the first,
> > solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes).
> And
> > a second, solved by the pool (1 in Difficulty shares). A valid block
> would
> > have to exhibit a valid Share Hash AND a valid Pool Hash in order to be
> > accepted.
>
> This only works for centralized pools, which are contrary to the health of
> the
> Bitcoin network. Decentralized pools cannot have a secret.
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120604/2e959c8a/attachment.html>

2023-06-07 10:11:38

- reply

📅 Original date posted:2012-06-04
📝 Original message:As I understand the attack, the attacker gets compensated for the shares
they earn, but the pool will be denied any valid blocks found. The
attacker DOES NOT have access to the Bitcoins earned in the unreported
block (only the mining pool has access to the Coinbase address and
transactions in the block).
So it's a zero-net-cost attack for the attacker (but no chance of making a
profit) to hurt the pool operator. The only way to detect such an attack
now is to look for "unlucky" miners; at the current difficulty, you can't
detect this cheat until many millions of shares have been earned w/o a
qualifying block. Since an attacker can also create many fake identities,
they can avoid detection indefinitely by abandoning each account after a
million earned shares.
I don't understand your proposal for fixing this. You would have to come
up with a scheme where:
- The miner can detect a qualifying hash to earn a share.
- Not be able to tell if the hash is for a valid block.
The way I would do this is to have a secret part (not shared with the
miners) of a block that is part of the merkle hash, which is also used in a
secondary hash. Difficulty is then divide into two parts: the first,
solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes). And
a second, solved by the pool (1 in Difficulty shares). A valid block would
have to exhibit a valid Share Hash AND a valid Pool Hash in order to be
accepted.
This would be a very major change to the Block structure. Given that
attackers do not have direct monetary gain from this attack, I'm not sure
we can justify it at this point.
On Sun, Jun 3, 2012 at 7:04 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote:
> > Does it have asymmetric payoff for an attacker, that is, over time does
> it
> > pay them more to spend their hashes attacking than just mining?
>
> That depends on the pool's reward scheme. Some complicated forms are
> capable
> of getting "bonus" earnings out of the pool. Under all systems, the
> attacker
> at least gains the "hurt the pool" benefit. Given the frequency of DDoS
> attacks on pools, it is clear there are people who will even pay for
> attacks
> that provide no other benefit than harming pools. Under all systems, the
> attacker doesn't lose out in any significant way.
>
> > My gut is that it pays less well than mining, meaning I think this is
> > likely a small problem in the aggregate, and certainly not something we
> > should try and fork the blockchain for until there's real pain.
>
> If we wait until there's real pain, it will be a painful fork. If we plan
> it
> 1-2 years out, people have time to upgrade on their own before it breaks.
>
> > Consider, for instance, whether it pays better than just mining bitcoins
> > and spending those on 'bonuses' for getting users to switch from a pool
> you
> > hate.
>
> With this attack, attackers can hurt the pool's "luck factor" *and* spend
> the
> bitcoins they earn to bribe users away.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120604/ed21dae7/attachment.html>

2023-06-07 10:02:52

- reply

📅 Original date posted:2012-04-03
📝 Original message:Alan, I'm coming in late to the conversation - do I understand that BIP 010
does not propose any changes to the protocol - but just an intermediate
data format that other clients might use to collect the need key material
to sign a multi-signature block?
If so - one might ask what the role of BIP's are if they actually do not
impact the protocol?
If there is any encapsulated data format that is expected to be interpreted
by clients - I'd call that a "protocol change"; but I take it in this
instance that you will transmit these signature block out of band from the
client ... yet they would have to be parsed and converted into a
Transaction Script once collected by SOME client? Would we expect the
standard client do so?
Sorry if this has been discussed before - I'm trying to understand the
proposal.
On Tue, Apr 3, 2012 at 2:12 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> **
> Just to clarify, I'm not proposing anything to the protocol itself.
> Simply that some applications might benefit from users being to sign
> messages with existing Bitcoin identities, and what can we do to
> accommodate that (out of band)? It's not a high priority, but I think it's
> potentially useful, and most codebases already have everything they need in
> place to implement it.
>
>
>
> On 04/03/2012 04:04 PM, Peter Vessenes wrote:
>
> I don't think it's minimally invasive to layer PGP's web of trust on top
> of Bitcoin, in fact, the opposite.
>
> From a certain angle, bitcoin exists as a sort of answer / alternate
> solution to the web of trust. Digital cash with an existing web of trust in
> place was a working concept in the mid-1990s, courtesy of David Chaum, I
> believe.
>
> I totally agree on the kitchen sink concern; I would personally like to
> see something like a one-year required discussion period on all
> non-security changes proposed to the blockchain protocol. We know almost
> nothing about how bitcoin will be used over the next 20 years; I believe
> it's a mistake to bulk up the protocol too rapidly right now.
>
> There's a famous phrase from the founder of Lotus about Lotus'
> engineering process: "add lightness." The equivalent for protocol design
> might be "add simplicity." I'd like to see us adding simplicity for now,
> getting a core set of tests together for alternate implementations like
> libbitcoin, and thinking hard about the dangers of cruft over a 10+ year
> period when it comes to a technology which will necessarily include a
> complete history of every crufty decision embodied in transaction histories.
>
> Peter
>
>
> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj at gmail.com> wrote:
>
>>
>> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke at dashjr.org> wrote:
>>
>>> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
>>> > We should avoid reinventing the wheel, if we can. I think we should
>>> > extend existing standards whenever possible.
>>>
>>> I wonder if it's possible to make sigs compatible with PGP/EC ?
>>>
>>
>> Or we could take a step back, further into "don't reinvent the wheel"
>> territory. Why not simply make use of PGP(/EC) to sign and verify messages?
>> It has many advantages, like an already existing web-of-trust and keyserver
>> infrastructure.
>>
>> I still feel like this is sign message stuff is dragging the kitchen sink
>> into Bitcoin. It's fine for logging into a website, what you use it for,
>> but anything that approaches signing email (such as S/MIME implementations
>> and handling different character encodings) is going too far IMO.
>>
>> Wladimir
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.http://p.sf.net/sfu/Boundary-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120403/84a5db0d/attachment.html>