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