Bernd Jendrissek [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-18 to 2019-04-07
💬 Posted a total of 7 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 18:17:37

- reply

📅 Original date posted:2019-04-07
📝 Original message:On Sun, 7 Apr 2019 at 17:45, simondev1 via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> ==Implementation==
> Sort transactions by FeeInSatoshiPerByte (lowest first)
> For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the bytes of space used so far. Check if summed up bytes of space used so far is smaller or equal than the formula result.
> If this is valid for each transaction then the blocksize is valid.
Doesn't this break CPFP? I think to avoid that you'll need to rework
your proposed algorithm to treat chains of transactions as a group.
(And note that you could have multiple transactions in one block that
depend on the same "parent" transaction, also in the same block.)

2023-06-07 18:10:35

- reply

📅 Original date posted:2018-02-09
📝 Original message:On 9 February 2018 at 12:55, Maksim Solovjov via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 2) I can launch bitcoind in -regtest regime.
> But when I launch bitcoin-cli -regtest setgenerate true 101
> I get an error:
>>
>> error code: -32601
>> error message:
>> Method not found
setgenerate was removed in 0.13.0. See doc/release-notes/release-notes-0.13.0.md
> 3) If I try bitcoin-cli getinfo
> I get an error:
>>
>> error: Could not locate RPC credentials. No authentication cookie could be
>> found, and no rpcpassword is set in the configuration file
>> (/Users/..../Library/Application Support/Bitcoin/bitcoin.conf)
getinfo is also deprecated or already removed. (Which version did you
install?) But even before that, you should probably heed the warning
and note that you don't seem to have a bitcoin.conf in a place where
bitcoin-cli can find it.

2023-06-07 15:41:01

- reply

📅 Original date posted:2015-06-27
📝 Original message:> In some ways, however, to me at
> least - Bitcoin is like Windows 3.11.
[...]
> Now there is a huge debate about if there
> should ever be a Windows 95, XP, Pro, etc., that scales better and makes
> advances over time, but doesn’t support facets of older versions as it gets
> updated.
I like your analogy for how it frames blockchain compatibility in
terms of the backward compatibility that hopefully most
computer-literate people already understand, but there's a key
ingredient missing.
It's as if, if everyone in the world did somehow upgrade to Windows
95, it would become forever impossible to take a program written *on*
Windows 95 but *for* Windows 3.11, and successfully run it on a
Windows 3.11 computer. It would be as if cross-compilers from Windows
95 to Windows 3.11 didn't, and couldn't, exist. Any coins that have
post-hardfork coinbase outputs anywhere in their tree of inputs (a
Windows 3.11 program, that's written on a computer that has ever run a
Windows 95 program) can never be spent on the no-change side of the
fork.

2023-06-07 15:22:03

- reply

📅 Original date posted:2014-05-24
📝 Original message:On Sat, May 24, 2014 at 5:57 AM, Ashley Holman <dscvlt at gmail.com> wrote:
> * As far as I can tell, this shouldn't change any game theory or incentives
> because nodes still receive blocks exactly as they do now, just sooner. The
> difference is, invalid blocks that meet the PoW will be broadcast to
> everyone, but this is nothing new since someone can peer with you and send
> you an invalid block already. Network DoS should not be a possibility since
> it is very expensive to make invalid blocks that meet network PoW.
The difference is that with cut-through forwarding of blocks, a
sufficiently motivated attacker (being willing to blow 25BTC's worth
of electricity on the effort) can subjugate the entire Bitcoin network
to its DoS attack, rather than having to connect to every node
individually and then still have those individual nodes reject that
invalid block without relaying any knowledge of its existence.
An attack could also take the form of a block body that never arrives
- a sort of teergrube attack, where the goal is to get the network
mining empty block upon empty block on top of that valid-PoW header
whose body never arrives. It doesn't have to be with an explicitly
invalid block.
Could one mitigate such attacks by allowing nodes to send a message to
the effect of, "Oops, I know that header i just sent is valid PoW, but
I'd like you to forget about it - I think its body is invalid"?

2023-06-07 15:21:40

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Mon, May 19, 2014 at 5:09 PM, Mike Hearn <mike at plan99.net> wrote:
> Most companies (Google certainly included) have therefore banned their staff
> from reading patents,
Bitcoin is not Google though, and applying the same patent protocols
to Bitcoin as in Google is drawing a false equivalence between the
two. Google can survive single or triple damages, so it makes sense to
hope that of those patents you necessarily violate due to the size of
your operations, they attract only single damages. Google has so many
fingers in so many pies that violating some patents is a question of
when, not if. Bitcoin has a far narrower scope than trying to take
over the world (and moon).
Happy reading: http://endsoftpatents.org/2010/03/transcript-tridgell-patents/
TL;DR: If even single damages result in commercial death, you better
pay attention to patents, to reduce the chances of accidentally
running into one.
(But Bitcoin is not ccache either - it's all about money and it isn't
inconceivable that a patent infringement suit might not result in
commercial death. The right answer here isn't as obvious as you make
it out to be.)

2023-06-07 15:21:18

- reply

📅 Original date posted:2014-05-13
📝 Original message:On Tue, May 13, 2014 at 3:21 AM, Peter Grigor <peter at grigor.ws> wrote:
> This was originally submitted to the bitcoin github issue manager. I'm
> re-posting here.
>
> I propose the transaction fee should be calculated from a percentage of the
> input amount divided by the confirmations of the input multiplied by the
> number of inputs.
For reference: https://github.com/bitcoin/bitcoin/issues/4171
I think the responses in the issue tracker already adequately address
why this doesn't belong in *Bit*coin. Your cure is worse than the
disease, IMHO.

2023-06-07 15:13:48

- reply

📅 Original date posted:2014-02-18
📝 Original message:[Ick, resending to list due to From: snafu(s)]
On Tue, Feb 18, 2014 at 11:47 PM, Peter Todd <pete at petertodd.org> wrote:
> What specifically do you dislike about X.509? The technical standard or
> the infrastructure around it? (IE the centralized authorities)
I'm not the one who was complaining, but what I dislike is that a
certificate can have only one issuer. Cross-signing doesn't address my
dislike: it's different enough from being a certificate's single
issuer that it leaves too much power in the CAs' hands, IMHO.
It isn't so much the centralization per se that I object to, but the
way that the technical standard encourages concentration in the
infrastructure. See
http://lair.fifthhorseman.net/~dkg/tls-centralization/#Why_does_the_architecture_encourage_concentration%3F
I've been (slowly) working on a patch to allow pki_data to contain
more than just the single certificate chain that the
single-issuer-only format insists on, but I'm making as many steps
back as forward, being unsure of the right way to do it. Implementing
an OpenPGP-based pki_type would probably be better, but hacking x509+*
seems like a lower-hanging fruit.