Jannes Faber [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-07 to 2017-04-07
💬 Posted a total of 15 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 17:59:20

- reply

📅 Original date posted:2017-04-07
📝 Original message:On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Ethically, this situation has some similarities to the DAO fork.
>
>
> Much better analogy:
>
> 1. An ISV make software which makes use of an undocumented OS feature.
> 2. That feature is no longer present in the next OS release.
> 3. ISV suffers losses because its software cannot work under new OS, and
> thus people stop buying it.
>
> I think 99% of programmers would agree that this loss was inflicted by a
> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
> undocumented features is something you do on your own risk.
>
Right. And in this case, code still is law: if the code specifies a version
number field and some miner finds an optimization that only works when the
version number == 1 then it's his own problem once the network upgrades to
version 2. In no way is there anything ethical about blocking the upgrade.
History is not an indicator of the possible values any field can hold in
the future. Limiting your operation to some arbitrary subset is at your own
risk.
Regarding the comparison: I haven't heard anyone even suggest rolling back
the last year of the blockchain to undo the damage already done, any
comparison can end there. If Jonathan wants to persist with this comparison
it would be more like people deciding to stop further funding of the hacked
contract. Yeah, that evil.
--
Jannes Faber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/ea9891e9/attachment.html>

2023-06-07 17:52:32

- reply

📅 Original date posted:2016-08-09
📝 Original message:Wow. No value judgement, but 1980 called, they want their radio broadcast
for analogue modems back. Both very cool and very cringe worthy.
It sounds quite horrible tbh. Imagine this being as pervasive as bar and qr
codes. And it's as meaningful and unpleasant to the human ear as a qr code
is to the eye.
Please think of something like using a Mozart symphony as the carrier wave
onto which you modulate your signal. Let the notes last a little longer to
represent a 1 bit. Or change the tempo. Or add an echo. Make it so the
listener can interpret it as a generic not too annoying tune and not even
realise it's different every time without being an audiophile.
Maybe have a 100 different base tunes from mozart to hiphop so the user can
pick one suitable to their audience and context. Maybe have some that don't
interfere with human speech frequencies so narrator can keep talking right
over it.
I guess it may be tricky because you want your signal to survive
re-encoding as increased playback speeds.
Another consideration: you want a preamble that is very easy to detect, so
it doesn't cost a lot of CPU (battery) to have your podcast player
continuously scanning for these things.
Not sure all these wishes are possible at the same time, but surely there's
research around on some?.
On 10 Aug 2016 1:28 a.m., "Daniel Hoffman via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699 at gmail.com
> > wrote:
>
>> It wouldn't be feasible in the vast majority of cases, but I can't think
>> of a reason why it can't be built into the standard.
>>
>> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>>> were to encode any extra information (such as amount), it would be useful
>>> to include a checksum for the entire message. This checksum could possibly
>>> be used instead of the checksum in the address.
>>>
>>> Trevin
>>>
>>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Daniel,
>>>> Thanks for proposing this. I think this could have some useful use
>>>> cases as you state. I was wondering what you would think to adding some
>>>> additional tones to optionally denote an amount (in satoshis?).
>>>>
>>>> (FYI, actual link is here: https://github.com/Dako300/BIP )
>>>>
>>>> Justin
>>>>
>>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>>> (depending on type, 2 bit only for low quality audio like american
>>>>> telephone lines), and generates a tone based upon that value. This started
>>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>>> having a Shazam-esque app (or a media player with this capability) that
>>>>> gives me an address automatically would be wonderful for both the consumer
>>>>> and producer. Comes with error correction built into the protocol
>>>>>
>>>>> You can see the full specification of the BIP on my GitHub page (
>>>>> https://github.com/Dako300/BIP-0153).
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Justin W. Newton
>>>> Founder/CEO
>>>> Netki, Inc.
>>>>
>>>> justin at netki.com
>>>> +1.818.261.4248
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/a08aa8b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/a08aa8b1/attachment-0001.tiff>

2023-06-07 17:50:37

- reply

📅 Original date posted:2016-05-11
📝 Original message:On 11 May 2016 at 16:18, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Jorge Timón said..
> > What do you mean by "embrace" in the context of a patented optimization
> that one miner can prevent the rest from using?
>
> Everyone seems to assume that one ASIC manufacturer will get the advantage
> of AsicBoost while others won't. If a patent license is non-exclusive, then
> all can.
>
>
1. Whatever way you look at it, it will be an extra barrier of entry (cost,
legal hassle, more complex chip design) for any new ASIC manufacturer
trying to enter the market. That counters free competition and thus
decentralization.
2. Why would you want to put yourself in the central spot of the big
decider on who gets access to the technology (and therefore the whole
mining game) and who doesn't. You're not afraid of NSA knocking on your
door to politely hand you their blacklist? You don't think this counters
all the years of hard work that went into Bitcoin exactly to avoid any such
central points of authority?
P.S. I'm not decided yet on being for or against a HF to ban AsicBoost
myself, nor does my opinion count for much. But I think I do see real
problems, like the above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/58f1e77b/attachment-0001.html>

2023-06-07 17:50:35

- reply

📅 Original date posted:2016-05-11
📝 Original message:On 11 May 2016 at 12:36, Henning Kopp <henning.kopp at uni-ulm.de> wrote:
> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev
> wrote:
> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > There is no way to tell from a block if it was mined with AsicBoost or
> > > not. So you don’t know what percentage of the hashrate uses AsicBoost
> at
> > > any point in time. How can you risk forking that percentage out? Note
> that
> > > this would be a GUARANTEED chain fork. Meaning that after you change
> the
> > > block mining algorithm some percentage of hardware will no longer be
> able
> > > to produce valid blocks. That hardware cannot “switch over” to the
> majority
> > > chain even if it wanted to. Hence you are guaranteed to have two
> > > co-existing bitcoin blockchains afterwards.
> > >
> > > Again: this is unlike the hypothetical persistence of two chains after
> a
> > > hardfork that is only contentious but doesn’t change the mining
> algorithm,
> > > the kind of hardfork you are proposing would guarantee the persistence
> of
> > > two chains.
> > >
> >
> > Assuming AsicBoost miners are in the minority, their chain will
> constantly
> > get overtaken. So it will not be one endless hard fork as you claim, but
> > rather AsicBoost blocks will continue to be ignored (orphaned) until they
> > stop making them.
>
> At least until a difficulty adjustment on the AsicBoost chain takes
> place. From that point on, both chains, the AsicBoost one and the
> forked one will grow approximately at the same speed.
>
>
No: you are still assuming AsicBoost miners would reject normal blocks.
They don't now and they would have to specifically code for that as a reply
to AsicBoost being banned. So there won't be two chains at all, only the
main chain with a lot (more than usual) of short (few blocks) forks. Each
forks starts anew, it's not one long fork. Therefore there is no
"difficulty adjustment on the AiscBoost chain".
Now if they do decide to ban non-AsicBoost blocks as a response to being
banned themselves, they're just another altcoin with a different PoW and no
one would have a reason to use them over Bitcoin (apart from maybe selling
those forked coins asap).
You're confused about what "longest" means as well: it's not just the
number of blocks, it's the aggregate difficulty that counts: so AsicBoost
would never become "longer" (more total work) either.
Hope this helps clear things up.
--
Jannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/9f723302/attachment.html>

2023-06-07 17:48:47

- reply

📅 Original date posted:2016-02-07
📝 Original message:On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said,
I surveyed several of the biggest infrastructure providers and the btcd
lead developer and they all agree "28 days is plenty of time."
28 days doesn't sound like enough for exchanges and others holding 3rd
party coins. They will have to start untangling the Bitcoins from
classiccoins immediately, while pausing all withdrawals. They *must* be
able to send their customers both coins as separate withdrawals. If not,
that amounts to theft of their customers funds.
(Note that the above describes the honest exchanges. Imagine the dishonest
ones that simply steal the classiccoins from their customers and sell them
for their own profit.)
The only other option is guaranteeing customers both coins in one
transaction, which they can't.
Surely you can't expect small entities to start putting in massive man
hours into this even before the hard fork has been triggered? Or even big
entities to have all that implemented and tested within *20* working days?
--
Jannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/1c6a2ee5/attachment.html>

2023-06-07 17:47:05

- reply

📅 Original date posted:2015-12-25
📝 Original message:On 25 Dec 2015 12:15 p.m., "Ittay" <ittay.eyal at cornell.edu> wrote:
> As for masquerading as multiple small pools -- that's a very good point,
with a surprising answer: it doesn't really matter. An attacker attacks all
parts of the open pool proportionally to their size, and the result is
basically identical to that of attacking a single large pool.
While true, that's only relevant to the indiscriminate attacker! The
vigilante attacker that wants to hurt only pools that are too large,
doesn't even know that there's a need to attack as all of them seem small.
That's what i was saying.
>
> On Mon, Dec 21, 2015 at 1:39 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> If you're saying a block withholding attack is a nice weapon to have to
dissuade large pools, isn't that easily defeated by large pools simply
masquerading as multiple small pools? As, for all we know, ghash may have
done?
>>
>> If you don't know who to attack there's no point in having the weapon.
While that weapon is still dangerous in the hands of others that are
indiscriminate, like the solo miners example of Peter Todd.
>>
>> Sorry if i misunderstood your point.
>>
>>
>> --
>> Jannes
>>
>> On 20 December 2015 at 18:00, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:
>>>>
>>>> There are a number of techniques that can be used to detect block
>>>> withholding attacks that you are not aware of. These techniques usually
>>>> have the characteristic that if known they can be avoided, so obviously
>>>> those who know about them are highly reluctant to reveal what exactly
>>>> they are. I personally know about some of them and have been asked to
>>>> keep that information secret, which I will.
>>>
>>>
>>> Indeed, there are lots of weak measures that one could employ against
>>> an uninformed attacker. As I mentioned before, these are unlikely to be
>>> effective against a savvy attacker, and this is a good thing.
>>>
>>>>
>>>> In the context of KYC, this techniques would likely hold up in court,
>>>> which means that if this stuff becomes a more serious problem it's
>>>> perfectly viable for large, well-resourced, pools to prevent block
>>>> withholding attacks, in part by removing anonymity of hashing power.
>>>> This would not be a positive development for the ecosystem.
>>>
>>>
>>> KYC has a particular financial-regulation connotation in Bitcoin
circles,
>>> of which I'm sure you're aware, and which you're using as a spectre.
>>> You don't mean government-regulated-KYC a la FINCEN and Bitcoin
>>> exchanges like Coinbase, you are just referring to a pool operator
>>> demanding to know that its customer is not coming from its competitors'
>>> data centers.
>>>
>>> And your prediction doesn't seem well-motivated or properly justified.
>>> There are tons of conditionals in your prediction, starting with the
premise
>>> that every single open pool would implement some notion of identity
>>> checking. I don't believe that will happen. Instead, we will have the
bigger
>>> pools become more suspicious of signing up new hash power, which is a
>>> good thing. And we will have small groups of people who have some reason
>>> for trusting each other (e.g. they know each other from IRC,
conferences,
>>> etc) band together into small pools. These are fantastic outcomes for
>>> decentralization.
>>>
>>>> Secondly, DRM tech can also easily be used to prevent block withholding
>>>> attacks by attesting to the honest of the hashing power. This is being
>>>> discussed in the industry, and again, this isn't a positive development
>>>> for the ecosystem.
>>>
>>>
>>> DRM is a terrible application. Once again, I see that you're trying to
use those
>>> three letters as a spectre as well, knowing that most people hate DRM,
but
>>> keep in mind that DRM is just an application -- it's like pointing to
Adobe Flash
>>> to taint all browser plugins.
>>>
>>> The tech behind DRM is called "attestation," and it provides a
technical
>>> capability not possible by any other means. In essence, attestation can
ensure that
>>> a remote node is indeed running the code that it purports to be
running. Since
>>> most problems in computer security and distributed systems stem from not
>>> knowing what protocol the attacker is going to follow, attestation is
the only
>>> technology we have that lets us step around this limitation.
>>>
>>> It can ensure, for instance,
>>> - that a node purporting to be Bitcoin Core (vLatest) is indeed
running an
>>> unadulterated, latest version of Bitcoin Core
>>> - that a node claiming that it does not harvest IP addresses from SPV
>>> clients indeed does not harvest IP addresses.
>>> - that a cloud hashing outfit that rented out X terahashes to a user
did
>>> indeed rent out X terahashes to that particular user,
>>> - that a miner operating on behalf of some pool P will not misbehave
and
>>> discard perfectly good blocks
>>> and so forth. All of these would be great for the ecosystem. Just
getting rid
>>> of the cloudhashing scams would put an end to a lot of heartache.
>>>
>>>> > Keep in mind that when an open pool gets big, like GHash did and
>>>> > two other pools did before them, the only thing at our disposal used
>>>> > to be to yell at people about centralization until they left the big
>>>> > pools and reformed into smaller groups. Not only was such yelling
>>>> > kind of desperate looking, it wasn't incredibly effective, either.
>>>> > We had no protocol mechanisms that put pressure on big pools to
>>>> > stop signing up people. Ittay's discovery changed that: pools that
>>>> > get to be very big by indiscriminately signing up miners are likely
to
>>>> > be infiltrated and their profitability will drop. And Peter's post is
>>>> > evidence that this is, indeed, happening as predicted. This is a
>>>> > good outcome, it puts pressure on the big pools to not grow.
>>>>
>>>> GHash.io was not a pure pool - they owned and operated a significant
>>>> amount of physical hashing power, and it's not at all clear that their
%
>>>> of the network actually went down following that 51% debacle.
>>>
>>>
>>> Right, it's not clear at all that yelling at people has much effect. As
much
>>> fun as I had going to that meeting with GHash in London to ask them to
>>> back down off of the 51% boundary, I am pretty sure that yelling at
large
>>> open pools will not scale. We needed better mechanisms for keeping pools
>>> in check.
>>>
>>> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
>>> time when we should count our blessings, not work actively to render
>>> them inoperable.
>>>
>>>> Currently a significant % of the hashing power - possibly a majority -
>>>> is in the form of large hashing installations whose owners
individually,
>>>> and definitely in trusting groups, have enough hashing power to solo
>>>> mine. Eyal's results indicate those miners have incentives to attack
>>>> pools, and additionally they have the incentive of killing off pools to
>>>> make it difficult for new competition to get established, yet they
>>>> themselves are not vulnerable to that attack.
>>>
>>>
>>> There are indeed solo miners out there who can attack the big open
>>> pools. The loss of the biggest open pools would not be a bad outcome.
>>> Pools >25% pose a danger, and the home miner doesn't need a pool
>>> >25% for protection against variance.
>>>
>>>> > Peter, you allude to a specific suggestion from Luke-Jr. Can you
>>>> > please describe what it is?
>>>>
>>>> Basically you have the pool pick a secret k for each share, and commit
>>>> to H(k) in the share. Additionally the share commits to a target
divider
>>>> D. The PoW validity rule is then changed from H(block header) < T, to
be
>>>> H(block header) < T * D && H(H(block header) + k) < max_int / D
>>>
>>>
>>> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>>>
>>> Once again, this suggestion would make the GHash-at-51% situation
>>> possible again. Working extra hard to re-enable those painful days
>>> sounds like a terrible idea.
>>>
>>> - egs
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151225/352db21d/attachment-0001.html>

2023-06-07 17:47:03

- reply

📅 Original date posted:2015-12-21
📝 Original message:If you're saying a block withholding attack is a nice weapon to have to
dissuade large pools, isn't that easily defeated by large pools simply
masquerading as multiple small pools? As, for all we know, ghash may have
done?
If you don't know who to attack there's no point in having the weapon.
While that weapon is still dangerous in the hands of others that are
indiscriminate, like the solo miners example of Peter Todd.
Sorry if i misunderstood your point.
--
Jannes
On 20 December 2015 at 18:00, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:
>
>> There are a number of techniques that can be used to detect block
>> withholding attacks that you are not aware of. These techniques usually
>> have the characteristic that if known they can be avoided, so obviously
>> those who know about them are highly reluctant to reveal what exactly
>> they are. I personally know about some of them and have been asked to
>> keep that information secret, which I will.
>>
>
> Indeed, there are lots of weak measures that one could employ against
> an uninformed attacker. As I mentioned before, these are unlikely to be
> effective against a savvy attacker, and this is a good thing.
>
>
>> In the context of KYC, this techniques would likely hold up in court,
>> which means that if this stuff becomes a more serious problem it's
>> perfectly viable for large, well-resourced, pools to prevent block
>> withholding attacks, in part by removing anonymity of hashing power.
>> This would not be a positive development for the ecosystem.
>>
>
> KYC has a particular financial-regulation connotation in Bitcoin circles,
> of which I'm sure you're aware, and which you're using as a spectre.
> You don't mean government-regulated-KYC a la FINCEN and Bitcoin
> exchanges like Coinbase, you are just referring to a pool operator
> demanding to know that its customer is not coming from its competitors'
> data centers.
>
> And your prediction doesn't seem well-motivated or properly justified.
> There are tons of conditionals in your prediction, starting with the
> premise
> that every single open pool would implement some notion of identity
> checking. I don't believe that will happen. Instead, we will have the
> bigger
> pools become more suspicious of signing up new hash power, which is a
> good thing. And we will have small groups of people who have some reason
> for trusting each other (e.g. they know each other from IRC, conferences,
> etc) band together into small pools. These are fantastic outcomes for
> decentralization.
>
> Secondly, DRM tech can also easily be used to prevent block withholding
>> attacks by attesting to the honest of the hashing power. This is being
>> discussed in the industry, and again, this isn't a positive development
>> for the ecosystem.
>>
>
> DRM is a terrible application. Once again, I see that you're trying to use
> those
> three letters as a spectre as well, knowing that most people hate DRM, but
> keep in mind that DRM is just an application -- it's like pointing to
> Adobe Flash
> to taint all browser plugins.
>
> The tech behind DRM is called "attestation," and it provides a technical
> capability not possible by any other means. In essence, attestation can
> ensure that
> a remote node is indeed running the code that it purports to be running.
> Since
> most problems in computer security and distributed systems stem from not
> knowing what protocol the attacker is going to follow, attestation is the
> only
> technology we have that lets us step around this limitation.
>
> It can ensure, for instance,
> - that a node purporting to be Bitcoin Core (vLatest) is indeed running
> an
> unadulterated, latest version of Bitcoin Core
> - that a node claiming that it does not harvest IP addresses from SPV
> clients indeed does not harvest IP addresses.
> - that a cloud hashing outfit that rented out X terahashes to a user did
> indeed rent out X terahashes to that particular user,
> - that a miner operating on behalf of some pool P will not misbehave and
> discard perfectly good blocks
> and so forth. All of these would be great for the ecosystem. Just getting
> rid
> of the cloudhashing scams would put an end to a lot of heartache.
>
> > Keep in mind that when an open pool gets big, like GHash did and
>> > two other pools did before them, the only thing at our disposal used
>> > to be to yell at people about centralization until they left the big
>> > pools and reformed into smaller groups. Not only was such yelling
>> > kind of desperate looking, it wasn't incredibly effective, either.
>> > We had no protocol mechanisms that put pressure on big pools to
>> > stop signing up people. Ittay's discovery changed that: pools that
>> > get to be very big by indiscriminately signing up miners are likely to
>> > be infiltrated and their profitability will drop. And Peter's post is
>> > evidence that this is, indeed, happening as predicted. This is a
>> > good outcome, it puts pressure on the big pools to not grow.
>>
>> GHash.io was not a pure pool - they owned and operated a significant
>> amount of physical hashing power, and it's not at all clear that their %
>> of the network actually went down following that 51% debacle.
>>
>
> Right, it's not clear at all that yelling at people has much effect. As
> much
> fun as I had going to that meeting with GHash in London to ask them to
> back down off of the 51% boundary, I am pretty sure that yelling at large
> open pools will not scale. We needed better mechanisms for keeping pools
> in check.
>
> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
> time when we should count our blessings, not work actively to render
> them inoperable.
>
> Currently a significant % of the hashing power - possibly a majority -
>> is in the form of large hashing installations whose owners individually,
>> and definitely in trusting groups, have enough hashing power to solo
>> mine. Eyal's results indicate those miners have incentives to attack
>> pools, and additionally they have the incentive of killing off pools to
>> make it difficult for new competition to get established, yet they
>> themselves are not vulnerable to that attack.
>>
>
> There are indeed solo miners out there who can attack the big open
> pools. The loss of the biggest open pools would not be a bad outcome.
> Pools >25% pose a danger, and the home miner doesn't need a pool
> >25% for protection against variance.
>
> > Peter, you allude to a specific suggestion from Luke-Jr. Can you
>> > please describe what it is?
>>
>> Basically you have the pool pick a secret k for each share, and commit
>> to H(k) in the share. Additionally the share commits to a target divider
>> D. The PoW validity rule is then changed from H(block header) < T, to be
>> H(block header) < T * D && H(H(block header) + k) < max_int / D
>>
>
> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>
> Once again, this suggestion would make the GHash-at-51% situation
> possible again. Working extra hard to re-enable those painful days
> sounds like a terrible idea.
>
> - egs
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151221/bf51d088/attachment.html>

2023-06-07 17:46:10

- reply

📅 Original date posted:2015-12-11
📝 Original message:Segregated IBLT
I was just wondering if it would make sense when we have SW to also make
Segregated IBLT? Segregating transactions from signatures and then tune the
parameters such that transactions have a slightly higher guarantee and save
a bit of space on the signatures side.
IBLT should of course, most of the time, convey all transactions _and_ all
signatures. However, in suboptimal situations, at least the receiving miner
will be more likely to have all the transactions, just possibly not all the
signatures.
Assuming the miner was already planning on SPV mining anyway, at least now
she knows which transactions to remove from her mempool, taking away an
excuse to mine an empty block. And she can still verify most of the
signatures too (whatever % could be recovered from the IBLT).
I guess this does not improve the worst adversarial case for IBLT block
propagation, but it should improve the effectiveness in cases where the
"normal" IBLT would fail to deliver all transactions. Transactions without
signatures is better than no transactions at all, for a miner that's eager
to start on the next block, right? In "optimal" cases it would reduce the
size of the IBLT.
Sorry if this was already suggested.
--
Jannes
On 10 December 2015 at 13:54, Tamas Blummer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Note that the unused space in coin base input script allows us to
> soft-fork an additional SW Merkle tree root into the design,
> therefore please make sure the new SW data structure also has a new slot
> for future extension.
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151212/80703517/attachment.html>

2023-06-07 17:45:30

- reply

📅 Original date posted:2015-12-04
📝 Original message:1) (I would assume this is already current default behaviour, but just in
case.) Would it not make sense to *never* send a blockheader to an SPV
client unless the node itself fully validated that block? Regardless of who
mined the block and whether this verification flag has been set or not.
2) Besides having your verification flag in the block, would it not also
make sense to have such a flag in the P2P protocol when blocks (or headers)
are communicated? That way a node could simply do some quick sanity checks
(difficulty as anti-DOS) on an incoming block and then immediately
propagate it to the next (non-SPV) node, but with a flag "Looks good, but I
haven't fully validated it myself, so please don't blame me". And if the
block does turn out to be invalid, the node does not get banned if it was
honest about it.
3) With the above implemented, I can imagine miners running 2 (or more)
nodes side by side, one of them doesn't validate in order to reduce latency
and orphan rates, but the other one does validate and quickly signals the
first one if there's a problem. Both nodes don't necessarily need to be in
the same network or even on the same side of the Great Firewall. Of course
they would be whitelisting each other for trust, or the signal would need
to include some sort of proof.
This probably has been suggested many times already, sorry if this is a
dumb idea.
--
Jannes
On 4 December 2015 at 09:26, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> For discussion,
>
> A significant fraction of hashrate currently mines blocks without
> verifying them for a span of time after a new block shows up on the
> network for economically rational reasons. This otherwise harmful
> behavior can be made a beneficial to the whole network; but only if it
> is communicated.
>
> This BIP proposal suggests a communication channel and describes its
> use and the motivations for it. I wrote it in response to suggestions
> that Bitcoin Core add explicit support for this kind of mining, which
> could also implement best in class risk mitigations. I believe
> signaling the behavior is a necessary component for risk mitigation
> here.
>
> -----------------------------------------------------------------
>
> <pre>
> BIP: draft-maxwell-flagverify
> Title: Blockchain verification flag
> Author: Greg Maxwell <greg at xiph.org>
> Status: Draft
> Type: Standards Track
> Created: 2015-12-02
> </pre>
>
> ==Abstract==
>
> This BIP describes a flag that the authors of blocks can use to voluntarily
> signal that they have completely validated the content of their
> block and the blocks before it.
>
> Correct use of this signaling is not enforced internally to the network
> but if used it can act as a hint allowing more intelligent risk analysis.
>
> If deployed and adhered to, this mechanism turns otherwise harmful
> validation skipping by miners into a behavior which benefits the public.
>
> ==Summary==
>
> The version field in a Bitcoin block header is a 32-bit signed integer.
>
> The most significant bit (30) of the block version is defined to signal
> that
> the author of the block has validated the whole chain up to and including
> the
> content of the block.
>
> Conforming miners MUST NOT set this flag when they have not completely
> validated the prior block(s) or the content of their own block. Miners
> should continue to try to minimize the amount of time spent mining
> on a non-validated chain. Blocks which extend an invalid chain will
> continue to be rejected and ultimately orphaned as validation catches up.
>
> It is recommended, but not required, that miners also not set the flag on
> blocks
> created by the same device which created the block immediately prior. This
> will reduce the incorrect implication of independent validation when the
> two
> most recent blocks are both the product of the same, single, faulty system.
>
> The set state for the bit is defined as verified so that that
> un(der)maintained systems do not falsely signal validation.
>
> Non-verifying clients of the network may check this bit (e.g. checking
> that the version is >= 1073741824) and use it as an input to their risk
> modeling. It is recommended that once this BIP is widely accepted by the
> network that non-full-node wallets refrain from counting confirmations on
> blocks where the bit is not set.
>
> The authors of non-verifying clients should keep in mind that this flag
> is only correct with the cooperation of the block author, and even then
> a validating miner may still accidentally accept or produce an invalid
> block due to faulty hardware or software. Additionally, any miner which
> correctly uses this flag could stop doing so at any time, and might
> do so intentionally in order to increase the effectiveness of an attack.
> As a result of misunderstanding, misconfiguration, laziness, or other
> human factors some miners may falsely set the flag. Because invalid
> blocks are rare it may take a long time to detect misuse of the flag.
>
> As such, the accuracy of this field MUST NOT be strongly relied upon.
>
> Especially due to the non-enforceability of the flag, the user community
> should keep in mind that both setting the flag correctly and mining
> without verification (for brief periods of time) are healthy for the
> network. If participants are punished for following this specification
> they will simply lie, and its utility will be diminished.
>
> ==Motivation==
>
> Some applications of the Bitcoin system such as thin-client wallets make
> a strong assumption that all the authors of the blocks have faithfully
> verified the blockchain. Because many of these applications also take
> irreversible actions based on only one or two confirmations and the time
> between blocks is often very short, these clients are vulnerable to
> even small and short-duration violations of this assumption.
>
> Processing and propagation delays resulting from increased transaction
> load contribute to block orphaning when multiple blocks are found at
> close to the same time. This has caused some miners to work on extending
> the chain with the most proof-of-work prior to validating the latest
> block(s).
>
> Although this validation skipping undermines the security assumptions
> of thin clients, it also has a beneficial effect: these delays also
> make the mining process unfair and cause increased rewards for the
> largest miners relative to other miners, resulting in a centralization
> pressure. Deferring validation can reduce this pressure and improve
> the security of the Bitcoin system long term.
>
> This BIP seeks to mitigate the harm of breaking the thin client
> assumption by allowing miners to efficiently provide additional
> information on their level of validation. By doing so the
> network can take advantage of the benefits of bypassed
> validation with minimal collateral damage.
>
> ==Deployment==
>
> Because there is no consensus enforced behavior there is no special
> deployment strategy required. [BIP 9 will need to be updated.]
>
> ==Credits==
>
> Thanks goes to Jeremy Rubin for his two-phase mining suggestion
> which inspired this simplified proposal.
>
> ==Copyright==
>
> This document is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151204/bbdcc1da/attachment.html>

2023-06-07 17:45:13

- reply

📅 Original date posted:2015-11-24
📝 Original message:Few issues I can think of:
1. In its basic form this encourages address reuse. Unless the wildcard can
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making HD moot
to begin with.
2. Sounds pretty dangerous during reorgs. Maybe such a transaction should
include a block height which indicates the maximum block that any utxo can
match. With the requirement that the specified block height is at least 100
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must be
in that minimum block).
3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > This idea could be applied by having the wildcard signature apply to all
> > UTXOs that are of a standard form and paid to a particular address, and
> be
> > a signature of some kind of message to that effect.
>
> I think this is true. Not *all* transactions will be able to match the
> wildcard. For instance if someone sent some crazy smart contract tx to
> your address, the script associated with that tx will be such that it
> will not apply to the wildcard. Most "vanilla" utxos that I've seen
> have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
> address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
> apply to the wildcard.
>
> On 11/24/15, Dave Scotese via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > What is required to spend bitcoin is that input be provided to the UTXO
> > script that causes it to return true. What Chris is proposing breaks the
> > programmatic nature of the requirement, replacing it with a requirement
> > that the secret be known. Granted, the secret is the only requirement in
> > most cases, but there is no built-in assumption that the script always
> > requires only that secret.
> >
> > This idea could be applied by having the wildcard signature apply to all
> > UTXOs that are of a standard form and paid to a particular address, and
> be
> > a signature of some kind of message to that effect. I imagine the cost
> of
> > re-scanning the UTXO set to find them all would justify a special extra
> > mining fee for any transaction that used this opcode.
> >
> > Please be blunt about any of my own misunderstandings that this email
> makes
> > clear.
> >
> > On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
> >> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >>> **OP_CHECKWILDCARDSIGVERIFY**
> >>
> >>
> >> Some (minor) discussion of this idea in -wizards earlier today starting
> >> near near "09:50" (apologies for having no anchor links):
> >> http://gnusha.org/bitcoin-wizards/2015-11-24.log
> >>
> >> - Bryan
> >> http://heybryan.org/
> >> 1 512 203 0507
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >
> >
> > --
> > I like to provide some work at no charge to prove my value. Do you need a
> > techie?
> > I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> > <http://www.memeracing.net> (in alpha).
> > I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which
> > now accepts Bitcoin.
> > I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> > "He ought to find it more profitable to play by the rules" - Satoshi
> > Nakamoto
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/0140731a/attachment-0001.html>