Isidor Zeuner [ARCHIVE] on Nostr: đ
Original date posted:2014-02-10 đ Original message:> > What is the official ...
đ
Original date posted:2014-02-10
đ Original message:>
> What is the official response from the Bitcoin Core developers about
> MtGox's assertion that their problems are due to a fault of bitcoin, as
> opposed to a fault of their own?
>
> The technical analysis preluding this mess, was that MtGox was at fault for
> their faulty wallet implementation.
>
I'm not a core developer, but I would certainly hope that those
who have commit access to the Bitcoin repository don't let
themselves be pressured by a company holding back user funds in order
to get a patch included into the Bitcoin source code.
I think this is less a matter of whose fault it is if a company
running a custom wallet implementation has problems peering with a
network mostly running another, community-based wallet
implementation. It is a matter of common sense that it's just not
practical to try to quickly apply an update to a distributed network,
which may possibly cause problems with peering and consensus
finding. When working with a protocol based on mutual agreement of a
large user base, a single entity like MtGox would be better off trying
to have their preferred changes implemented slowly if at all, while
solving their immediate issues on their side. Problems with
transactions being accepted can often be solved by changing the wallet
client's way of peering with other nodes, without changing the
protocol at all.
Thinking this further, I am kind of surprised that something like this
can even become an issue worth discussing. I never heard of a bank
which would try to create pressure by suspending money withdrawals
until the TCP/IP protocol is changed to match their preferences.
Best regards,
Isidor Zeuner
Published at
2023-06-07 15:13:34Event JSON
{
"id": "59d85b93f66fd0479d3b983c7167afb2432de29ab22a2c1f7d7c85aeccefeff6",
"pubkey": "70950d9ef527ee56cd47d1cec909c3ddfa69de32fbea13cad10641ee6dc93e39",
"created_at": 1686150814,
"kind": 1,
"tags": [
[
"e",
"577cc67a59a48de104420345cc434c506c7be84ef1880846f65b1fed1155b978",
"",
"root"
],
[
"e",
"49a7ae9f8757d12d58955bf5e9f541042c4cea007cbac7e4528a8070172fe62e",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "đ
Original date posted:2014-02-10\nđ Original message:\u003e\n\u003e What is the official response from the Bitcoin Core developers about\n\u003e MtGox's assertion that their problems are due to a fault of bitcoin, as\n\u003e opposed to a fault of their own?\n\u003e\n\u003e The technical analysis preluding this mess, was that MtGox was at fault for\n\u003e their faulty wallet implementation.\n\u003e\n\nI'm not a core developer, but I would certainly hope that those\nwho have commit access to the Bitcoin repository don't let\nthemselves be pressured by a company holding back user funds in order\nto get a patch included into the Bitcoin source code.\n\nI think this is less a matter of whose fault it is if a company\nrunning a custom wallet implementation has problems peering with a\nnetwork mostly running another, community-based wallet\nimplementation. It is a matter of common sense that it's just not\npractical to try to quickly apply an update to a distributed network,\nwhich may possibly cause problems with peering and consensus\nfinding. When working with a protocol based on mutual agreement of a\nlarge user base, a single entity like MtGox would be better off trying\nto have their preferred changes implemented slowly if at all, while\nsolving their immediate issues on their side. Problems with\ntransactions being accepted can often be solved by changing the wallet\nclient's way of peering with other nodes, without changing the\nprotocol at all.\n\nThinking this further, I am kind of surprised that something like this\ncan even become an issue worth discussing. I never heard of a bank\nwhich would try to create pressure by suspending money withdrawals\nuntil the TCP/IP protocol is changed to match their preferences.\n\nBest regards,\n\nIsidor Zeuner",
"sig": "e4ce14850717709eb2d2391fe63687d9475e60bae7cd02111590755499161bf84b37e4164b5dd8c85e02601a8bdb97ee76b39f62056870aa821bd65b63e08e9c"
}