Arne Brutschy [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-04-07 to 2015-07-16
💬 Posted a total of 5 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 15:42:24

- reply

📅 Original date posted:2015-07-16
📝 Original message:Hello,
What are these pre- and post-Hearn-relay drop rules you are speaking
about? Can anybody shed some light on this? (I am aware of the
minrelaytxfee setting proposed in the 0.11.0 release notes, I just
don't see what this has to do with Mike Hearn, BitcoinXT, and whether
there's a code change related to this that I missed).
Related: is there somewhere a chart that plots `estimatefee` over
time? Would be interesting to see how the fee market evolved over
these past weeks.
Regards
Arne
On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote:
> With my black hat on I recently performed numerous profitable
> double-spend attacks against zeroconf accepting fools. With my
> white hat on, I'm warning everyone. The strategy is simple:
>
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.
> anything that miners don't always accept.
>
> tx2: After merchant gives up valuable thing in return, normal tx
> without triggering spam protections. (loltasticly a Mike Hearn
> Bitcoin XT node was used to relay the double-spends)
>
> Example success story: tx1 paying Shapeshift.io with 6uBTC output
> is not dust under post-Hearn-relay-drop rules, but is dust under
> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not
> paying Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all
> miners who have reverted Hearn's 10x relay fee drop as recommended
> by v0.11.0 release notes and accept these double-spends.
> Shapeshift.io lost ~3 BTC this week in multiple txs. (they're no
> longer accepting zeroconf)
>
> Example success story #2: tx1 with post-Hearn-relay drop fee,
> followed by tx2 with higher fee. Such stupidly low fee txs just
> don't get mined, so wait for a miner to mine tx2. Bought a silly
> amount of reddit gold off Coinbase this way among other things. I'm
> surprised that reddit didn't cancel the "fools-gold" after tx
> reversal. (did Coinbase guarantee those txs?) Also found multiple
> Bitcoin ATMs vulnerable to this attack. (but simulated attack with
> tx2s still paying ATM because didn't want to go to trouble of good
> phys opsec)
>
> Shoutouts to BitPay who did things right and notified merchant
> properly when tx was reversed.
>
> In summary, every target depending on zeroconf vulnerable and lost
> significant sums of money to totally trivial attacks with high
> probability. No need for RBF to do this, just normal variations in
> miner policy. Shapeshift claims to use Super Sophisticated Network
> Sybil Attacking Monitoring from Blockcypher, but relay nodes !=
> miner policy.
>
> Consider yourself warned! My hat is whiter than most, and my skills
> not particularly good.
>
> What to do? Users: Listen to the experts and stop relying on
> zeroconf. Black hats: Profit!
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Arne Brutschy <abrutschy at xylon.de>

2023-06-07 15:34:15

- reply

📅 Original date posted:2015-05-08
📝 Original message:Hello,
At DevCore London, Gavin mentioned the idea that we could get rid of
sending full blocks. Instead, newly minted blocks would only be
distributed as block headers plus all hashes of the transactions
included in the block. The assumption would be that nodes have already
the majority of these transactions in their mempool.
The advantages are clear: it's more efficient, as we would send
transactions only once over the network, and it's fast as the resulting
blocks would be small. Moreover, we would get rid of the blocksize limit
for a long time.
Unfortunately, I am too ignorant of bitcoin core's internals to judge
the changes required to make this happen. (I guess we'd require a new
block format and a way to bulk-request missing transactions.)
However, I'm curious to hear what others with a better grasp of bitcoin
core's internals have to say about it.
Regards,
Arne

2023-06-07 15:19:01

- reply

📅 Original date posted:2014-04-20
📝 Original message:Hello,
> While SI units are great for people well versed in them, there is a
> very good reason people aren't asking for 100 micro dollars in change.
> The average person is not going to be confident that the prefix they
> are using is the correct one, people WILL send 1000x more or less than
> intended if we go down this road, and these mistakes will happen
> frequently. Labeling should be easy enough for kindergarten kids.
Agree - but why do you propose not only a new label but also a different
subunit?
Also, everybody in the metric world is used to the milli- prefix due to
meters and millimeters. It's not such a stretch to expect people to
master that; but I agree that most people would struggle with microbitcoins.
> I propose that users are offered a preference to denominate the
> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
> equals one million bits (bits) and one bit equals 100 satoshis.
There have been many proposals for more or less arbitrary subunits. What
would be the merit of your proposal? I don't really follow the reasoning
that it's better if it's uncommon for everyone rather than just uncommon
for people not used to metric units.
Regarding the label of a "bit": I have to agree with the others that bit
is heavily overused as a unit, but I am a computer scientist, so I don't
have the "average joe's" perspective on this. I find it weird to use as
it's already in use in English - "a bit of work" etc
I don't really see the advantage of a "bit" - it is part of "bitcoin"
and it's short, but that's about it. I think we are free to pick
anything we want for a label, so why not avoid ambiguities?
See this thread for many creative ideas for labels (and another
arbitrary subunit proposal:
https://bitcointalk.org/index.php?topic=396522.0
Arne

2023-06-07 15:19:01

- reply

📅 Original date posted:2014-04-20
📝 Original message:I agree that overloading isn't an issue when necessary, but my point was
that the necessity is lacking. If we're free to pick anything, why pick
something that is overloaded?
Moreover, "bit" is an abbreviation of bitcoin and might be confused with
it. Most currencies use a work that is phonetically very different and
short, so why not do the same?
Pluk, or cred, or finney (as proposed the thread I posted), or
whichever. We could call it "unsp" for unspent ;)
Arne
On 20/04/14 20:11, Mike Caldwell wrote:
> It is a paradigm that is easy to explain and grasp for neurotypical
> people.
>
> The average mind has no problem overloading words and distinguishing
> the intended meaning from context. For most people, overloading a
> single syllable word with a new meaning is much less complicated than
> using a unique 3+ syllable word like satoshi or micro-anything.
>
> Doing software development warps our minds to demand fully qualified
> names for everything. We know our compilers would say "bit? Fatal
> error 0xaaabbbbwtf, can't continue, not sure if you mean a Boolean or
> a dog bite". But this peculiarity should not be projected onto the
> people we are trying to get bitcoin to appeal to, not if we want them
> to feel like we think about their experience.
>
> If I were to say "a Bitcoin can be divided into a million bits", less
> than 0.1% of average joes would think I was talking about German
> beers or the thing that goes in horses mouths. Really, most people
> are good at using context to relate this to "a dollar can be divided
> into 100 cents" and accepting it. This requires much less of their
> mind resources than using SI prefixes correctly or learning 3
> syllable words that (to them) have no instantly apparent relationship
> to Bitcoin.
>
> Mike
>
> Sent from my iPhone
>
> On Apr 20, 2014, at 11:44 AM, "Arne Brutschy" <abrutschy at xylon.de>
> wrote:
>
>>> I propose that users are offered a preference to denominate the
>>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>>> equals one million bits (bits) and one bit equals 100 satoshis.
>>
>> There have been many proposals for more or less arbitrary subunits.
>> What would be the merit of your proposal? I don't really follow the
>> reasoning that it's better if it's uncommon for everyone rather
>> than just uncommon for people not used to metric units.
>>
>> Regarding the label of a "bit": I have to agree with the others
>> that bit is heavily overused as a unit, but I am a computer
>> scientist, so I don't have the "average joe's" perspective on this.
>> I find it weird to use as it's already in use in English - "a bit
>> of work" etc
>
> ------------------------------------------------------------------------------
>
>
Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:17:47

- reply

📅 Original date posted:2014-04-07
📝 Original message:> The bottleneck is not bulk disk space, but rather IOPS.
Exactly. I stopped running a full node on both of my desktops machines
in the last month. Both systems were simply becoming very noticeable
(=unbearably) sluggish. I am also running dedicated nodes, which are
fine, but on a desktop latency is a major issue (or, let's say, a
different issue than on a server).
I didn't notice any network latency, but that's hard to judge as our
internet is pants anyway.
Arne
PS: my machines aren't the newest, but still do a stellar job (without
bitcoind running ;)