<unnamed>

Public Key

npub1t9txg5aevth45pu9hcz075tj3ch25fydn8c38wew90qjjdjv3rqq3r6cf0

Profile Code

nprofile1qqs9j4ny2wuk9m66q7zmup8l29egut42yjxenugnhvhzhsffxexg3sqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvhzmqcm

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:23:36 UTC

- reply

📅 Original date posted:2014-07-04
📝 Original message:Just some general comments on this topic/discussion.
I suspect that there exist no algorithms which cannot be done better in
an application-specific device than in a general purpose computer. And
if there is such a thing, then it must necessarily perform best on one
specific platform, making that platform the de facto application
specific device.
I'm not sure how one would go about proving or disproving that, but it
seems very likely to be true.
IO-bound is exactly the same as memory bound, for devices that have
enough memory. 20 GB is already trivial today, and you don't really get
into ask-the-wife-for-permission money until you cross 128 GB. The
exception would be if the IO was to an oracle outside of the device's
control, and artificially limited in throughput. Such a centralized
oracle would be contrary to the goals usually stated by people thinking
about anti-ASIC designs, so there isn't much point.
Keeping the algorithm simple, and ASIC-easy, has one other advantage.
Just about anyone can sit down and design an ASIC for SHA, for example,
leading to diversity in the marketplace. A harder algorithm can still
be made into an ASIC (or more generally into an ASD), but will require
more skilled designers, more expensive fabrication, etc. This actually
concentrates the ASIC advantage into the hands of fewer people, which
again, is contrary to the stated goals.

2023-06-07 15:17:34 UTC

- reply

📅 Original date posted:2014-04-08
📝 Original message:Multi-sig requires infrastructure. It isn't a magic wand that we can
wave to make everyone secure. The protocols and techniques necessary
don't exist yet, and apparently no one has much of an incentive to
create them.
I mean no offense, and I don't mean to pick on you. Your post stuck out
while I was reading. Secure multi-sig is what we all want, but wanting
apparently isn't enough to make it happen.
Other random notes from reading this 50+ post thread:
Perhaps we should have a config flag to prevent a node from serving IBD
to new nodes. IBD crushes marginal machines, particularly those with
spinning disks. This has been extensively discussed elsewhere.
The ideal IBD hosts are serving the blockchain out of a RAM disk. Is
there any interest in setting up a network of volunteers to host
expensive servers with fast connections? It doesn't look too terribly
difficult to figure out when a node has stopped asking for blocks in
bulk, so we could add another config flag to eject nodes once they are
done booting.
Even ignoring IBD, I think that we are gradually outgrowing cheapass
hosting options. Personally, I long ago gave up on answering forum
questions about running nodes on virtual servers and VPSs. It is
certainly still possible to run bitcoind on small boxes, but it isn't
trivial any more. (Anyone running on less than my Athlon XP 1800+ with
896 MB RAM?) If we want those nodes back, we need to optimize the hell
out of the memory use, and even that might not be enough.
Eric Martindale wrote:
>
> We need to make it so mind-numbingly simple to "run Bitcoin correctly"
> that the average user doesn't find reasons to do so in the course of
> normal use. Right now, Coinbase and Bitstamp are winning in the user
> experience battle, which technically endanger the user, and by proxy
> the Bitcoin network.
>
> Multi-sig as a default is a start. It won't succeed unless the user
> experience is simply better than trusted third parties, but we need to
> start the education process with the very basic fundamental: trusting
> a third-party with full access to your Bitcoin is just replacing one
> centralized banking system with another.
>
>

2023-06-07 15:16:54 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:Matt Whitlock wrote:
> The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1.
>
At first, I thought this was a second April Fool's joke, but then I
looked and saw that all of the BIPs really do use this format. As far
as I can tell, we are using this insane format because RFC 822 predates
ISO 8601 by half a decade.
Since we don't have half a gajillion mail servers to patch, we could, if
we desired, adopt a sensible date format here. The cost to the
community would be minimal, with probably not more than a half dozen
people needing to update scripts. It could even be as simple as one guy
running sed s/parseabomination/parsedate/g

2023-06-07 15:15:59 UTC

- reply

📅 Original date posted:2014-03-25
📝 Original message:Troy Benjegerdes wrote:
> Mark Friedenbach wrote:
>> Bitcoin is not a centralized system, and neither is its development. I
>> don't even know how to respond to that. Bringing up altchains is a total
>> red herring.
>>
>> This is *bitcoin*-development. Please don't make it have to become a
>> moderated mailing list.
> When I can pick up a miner at Best Buy and pay it off in 9 months I'll
> agree with you that bitcoin *might* be decentralized. Maybe there's a
> chance this *will* happen eventually, but right now we have a couple of
> mining cartels that control most of the hashrate.
>
> There are plenty of interesting alt-hash-chains for which mass produced,
> general purpose (or gpgpu-purpose) hardware exists and is in high volume
> mass production.
Decentralized doesn't mean "everyone is doing it", it means "no one can
stop you from doing it". Observe bitcoin development. A few people do
the bulk of the work, a bunch more people (like me) do work ranging from
minor to trivial, and millions do nothing. And yet, it is still totally
decentralized because no one can stop anyone from making whatever
changes they want.
So it is also with mining. The world overall may make it impractical,
perhaps even foolish, for you to fire up your CPU and mine solo, but no
one is stopping you, and more to the point, no one is capable of
stopping you. There is no center from which you must ask permission.
On moderation, I note that moderation can also be done in a
decentralized fashion. I offer this long overdue example:
:0
* ^From.*hozer at hozed.org
/dev/null

2023-06-07 15:15:02 UTC

- reply

📅 Original date posted:2014-03-10
📝 Original message:I was trying to use bip10 for multisig and coinjoin, but there was a
problem with it. I'll have to look back at my notes, but I thought I
sent you a message about it. And then real life swallowed my bitcoin time...
I think the bottom line was that it would be useful in the generic case
with just one minor change. If there is interest, and it sounds like
there just may be, I can dust off my notes and see where I left it.
Probably should do it soon before someone implements it in PB or XML.
Alan Reiner wrote:
> Then of course I tried to do this with BIP 10
> <https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki> when
> Armory implemented offline-transactions two years ago. I got some
> positive feedback, but no one wanted to help improve it, etc. I guess
> nobody else was doing it and/or cared at the time. So I continue to
> use BIP 10 even though it's pretty crappy. I wanted it to be useful
> for multisig, too, but it has some deficiencies there (it was done
> when Armory was extremely young and OP_EVAL was still on the table).
>
> However, with all this activity, we should start thinking about that
> and discussing it. Otherwise, I'll just do my own thing again and
> probably end up with something that fits my own needs, but not anyone
> else's. Really though, multisig shouldn't require all the same app to
> work.
>
> -Alan
>
>
> On 03/10/2014 01:49 PM, Gavin Andresen wrote:
>> In my experience, best process for standardizing something is:
>>
>> 1) Somebody has a great idea
>> 2) They implement it
>> 3) Everybody agrees, "Great idea!" and they copy it.
>> 4) Idea gets refined by the people copying it.
>> 5) It gets standardized.
>>
>> Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
>> opinion...
>>
>>
>>
>>
>> On Mon, Mar 10, 2014 at 1:39 PM, Drak <drak at zikula.org
>> <mailto:drak at zikula.org>> wrote:
>>
>> I was wondering if there would be merit in a kind of BIP for a
>> payment protocol using multisig?
>>
>> Currently, setting up a multisig is quite a feat. Users have to
>> exchange public keys, work out how to get the public keys from
>> their addresses. If one of the parties are not savvy enough, an
>> malicious party could easily be setup that was 2 of 3 instead of
>> 2 of 2 where the malicious party generates the multisig
>> address+script and thus be able to run off with funds anyway.
>>
>> It's also terribly complex to generate and keep track of. There's
>> been a nice attempt at creating an browser interface at
>> coinb.in/multisig <http://coinb.in/multisig> but it still lacks
>> the kind of ease with created by the payment protocol. If there
>> was a BIP then it would go a long way to aiding future usability
>> of multisig wallet implementations.
>>
>> What are your thoughts?
>>
>> Drak
>>
>> ------------------------------------------------------------------------------
>> 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/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> ------------------------------------------------------------------------------
>> 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/13534_NeoTech
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> 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/13534_NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/7a45e78c/attachment.html>

2023-06-07 15:08:59 UTC

- reply

📅 Original date posted:2013-11-06
📝 Original message:One of the things that really gets me going is when someone devises a
model, tests it against itself, and then pretends that they've learned
something about the real world.
Naturally, the Selfish Mining paper is exactly this sort of nonsense.
Their model is one with no latency, and one where the attacker has total
visibility across the network. An iterated FSM is not a suitable
simulation of the bitcoin system. The bitcoin network does not have
states, and to the extent that you can pretend that we do, you can't
simulate transitions between them with static probabilities.
The authors understand this deep down inside, even though they didn't
work out the implications. They handwave the issue by assuming a total
sybil attack, and in true academic spirit, they don't realize that the
condition necessary for the attack is far, far worse than the attack itself.
Greg said he'd like to run some simulations, and I'm thinking about it
too. Unfortunately, he is busy all week, and I'm lazy (and also busy
for most of tomorrow).
If neither of us get to it first, I'm willing to pitch in 1 BTC as a
bounty for building a general bitcoin network simulator framework. The
simulator should be able to account for latency between nodes, and
ideally within a node. It needs to be able to simulate an attacker that
owns varying fractions of the network, and make decisions based only on
what the attacker actually knows. It needs to be able to simulate this
"attack" and should be generic enough to be easily modified for other
crazy schemes.
(Bounty offer is serious, but expires in one year [based on the earliest
timestamp that my mail server puts on this email], and /may/ be subject
to change if the price on any reputable exchange breaks 1000 USD per BTC
in that period.)
Basically, the lack of a decent network simulator is what allowed this
paper to get press. If the author had been able to see the importance
of the stuff he was ignoring, we wouldn't be wasting so much time
correcting him (and sadly the reporters that have no way to check his
claims).
https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663

2023-06-07 15:08:11 UTC

- reply

📅 Original date posted:2013-10-28
📝 Original message:Any reason not to use actual HTTP codes? I'm not aware of any major
deficiency in them. Most of them won't apply to us, which is fine, they
don't seem to apply to HTTP either. We can extend the scheme on our own
if we find a good reason to.
That implies 16 bits, or a varint. I would avoid a string or varstring
here; we already have a text field. Varint vs. 16 bits is a minor
issue, and arguments can be made in both directions. I flipped a coin
and got heads, so I'll say varint.
Gavin Andresen wrote:
> RE: use HTTP-like status codes:
>
> Okey dokey, I'll add a one-byte machine-readable HTTP-like status
> code. Unless y'all want a 32-bit status code. Or maybe a varint. Or a
> three-character numeric string. I really and truly don't care, but I
> am writing this code right now so whatever you want, decide quickly.
>
> If anybody has strong feelings about what the reject categories should
> be, then please take the time to write a specific list, I can't read
> your mind....
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131027/447ba632/attachment.html>

2023-06-07 15:08:08 UTC

- reply

📅 Original date posted:2013-10-26
📝 Original message:The HTTP status code system seems to work well enough, and seems to give
the best of both worlds. A 3 digit numeric code that is
machine-readable, and a freeform text note for humans.
The clever part about that system was in realizing that the numeric
codes didn't need to account for every possible error. They just need to
give the other node the most useful information, like "try that again
later, I'm having a temporary problem" vs. "That is just plain wrong and
it will still be wrong next time too, so don't bother to retry".
We can leave it to the humans to puzzle out the meaning of "403: values
of txid gives rise to dom!"
Gavin wrote:
>
> On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
>> Would it make sense to use either fixed length strings or maybe even enums?
> No. Enums or fixed length strings just make it harder to extend, for no benefit (bandwidth of 'reject' messages doesn't matter, they will be rare and are not relayed).
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:26:23 UTC

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: Luke-Jr argues that penalizing "non-standard" transactions or those with insufficient fees is not fair, as it is a policy decision, not a protocol violation. However, Gavin Andresen believes that assigning a point or two of badness to a peer sending one is reasonable.
📝 Original message:Luke-Jr wrote:
> On Thursday, September 15, 2011 8:56:24 AM kjj wrote:
>> Luke-Jr wrote:
>>> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
>>>> I'm looking for review of this pull request:
>>>> https://github.com/bitcoin/bitcoin/pull/517
>>> "Non-standard" transactions, or those with "insufficient" fees should not
>>> be penalised. These are properly relay/miner policy decisions, not
>>> protocol violations, and should be made more easily configurable, not
>>> punished for configuration.
>> A few non-standard transactions are probably legitimate. A whole bunch
>> of them are probably not. I would think that assigning a point or two
>> of badness to a peer sending one is pretty reasonable, with the
>> understanding that we would need to adjust that as the network evolves.
> No. There is no such thing as "non-standard transactions" really; it is simply
> "transactions outside of the bounds that I as a user/miner will relay/accept".
> It is perfectly legitimate for other users/miners to relay/accept transactions
> more liberally. By penalising for transactions falling outside of your
> *personal policies*, you would end up banning many legitimate nodes.
It is certainly true that standardness is an artificial construct that
only has meaning to this particular implementation of the software, but
no meaning in the context of the protocol or the system as a whole.
On the other hand, the vast, vast majority of all transactions follow a
particular pattern. If someone gives you one that doesn't match the
standard pattern, you might be a little suspicious, but it is no big
deal. But, if they emit dozens or hundreds, it is hardly unreasonable
to disconnect them until you figure out what's going on.

2023-06-07 02:26:17 UTC

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: Luke-Jr argues that "non-standard" transactions with insufficient fees should not be penalized as they are policy decisions, not protocol violations.
📝 Original message:Luke-Jr wrote:
> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
>> I'm looking for review of this pull request:
>> https://github.com/bitcoin/bitcoin/pull/517
> "Non-standard" transactions, or those with "insufficient" fees should not be
> penalised. These are properly relay/miner policy decisions, not protocol
> violations, and should be made more easily configurable, not punished for
> configuration.
>
>
A few non-standard transactions are probably legitimate. A whole bunch
of them are probably not. I would think that assigning a point or two
of badness to a peer sending one is pretty reasonable, with the
understanding that we would need to adjust that as the network evolves.

2023-06-07 02:25:24 UTC

- reply

📅 Original date posted:2011-09-13
🗒️ Summary of this message: Bitcoin's timejacking and related exploits can be fixed by overlapping block timestamps and using NTP, but new block timestamp rules are needed.
📝 Original message:Gavin Andresen wrote:
> Background:
>
> Timejacking:
> http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
>
> And a recent related exploit launched against the low-difficulty
> alternative chains:
> https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
>
>
> Seems to me there are two fundamental problems:
>
> 1) Bitcoin should be overlapping the ranges of block timestamps that
> it uses to calculate difficulty adjustments.
>
> 2) Bitcoin's "what time is it" code is kind of a hack.
>
>
> Fixing (1) would mean a potential block-chain split; before
> considering doing that I'd like to consider second-best solutions.
>
> Fixing (2) is easier; incorporating a ntp library and/or simply
> removing the bitcoin mining code from the client but requiring pools
> and miners to have accurate-to-within-a-minute system clocks (or their
> blocks will be "discouraged") seems reasonable to me. If you want to
> produce blocks that the rest of the network will accept, run ntp on
> your system.
>
> I THINK that fixing (2) will make (1) a non-issue-- if miners can't
> mess around with block times very much then it will be very difficult
> for them to manipulate the difficulty for their benefit.
>
The first thing I always do when I grab the source for my colo server is
patch util.cpp so that GetAdjustedTime() returns GetTime() with no
adjustment. But I'm the kind of guy that buys special GPS receivers
because stratum 2 isn't low enough and occasionally checks ebay for
caesium fountains.
NTP has been around for long enough now that there is no reason for the
client to screw with the clock. If the client sees different times on
the network, it should issue a warning, and if it is off too far, it
should give an error and fail to run (and/or peers should reject it).
But that doesn't solve the whole problem, because the block timestamp
checking is based on the assumption that the node is looking at the
bitcoin clock rather than the, ahem, real clock. If we change the idea
of network time to NTP, we will then need to write (and test!) new block
timestamp rules to account for the new assumptions.
I'm not sure that just fixing item 2 is going to stop the attacks found
by ArtForz, et al. Some of the attacks Art pointed out are particularly
bad because they change the incentive structure of the system, at least
in the short term. We need to flip that back around ASAP.
Also, this is going to cause problems for at least one pool operator.