<unnamed>

Public Key

npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrx

Profile Code

nprofile1qqsd22smwf23hwj8h6c5vwdpkm67dnvcvqlvh24x4vpqx9cgm8xygucpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc4df5ql

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:33:56 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:such a contract is a possibility, but why would big owners give an
exclusive right to such pools? It seems to me it'd make sense to offer
those for any miner as long as the get paid a little for it. Especially
when it's as simple as offering an incomplete transaction with the
appropriate SIGHASH flags.
a part of the reason I like this idea is because it will allow stakeholders
a degree of influence on how large the fees are. At least from the surface,
it looks like incentives are pretty well matched. They have an incentive to
not let the fees drop too low so the network continues to be usable and
they also have an incentive to not raise them too high because it'll push
users into using other systems. Also, there'll be competition between
stakeholders, which should keep the fees reasonable.
I think this would at least be preferable to the "let the miner decide"
model.
- Joel
On Fri, May 8, 2015 at 7:51 PM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joonatan Kaartinen wrote:
> > Matt,
> >
> > It seems you missed my suggestion about basing the maximum block size on
> > the bitcoin days destroyed in transactions that are included in the
> block.
> > I think it has potential for both scaling as well as keeping up a
> constant
> > fee pressure. If tuned properly, it should both stop spamming and
> increase
> > block size maximum when there are a lot of real transactions waiting for
> > inclusion.
>
> The problem with gating block creation on Bitcoin days destroyed is
> there's a strong potential of giving big mining pools an huge advantage,
> because they can contract with large Bitcoin owners and buy dummy
> transactions with large numbers of Bitcoin days destroyed on demand
> whenever they need more days-destroyed to create larger blocks.
> Similarly, with appropriate SIGHASH flags such contracting can be done
> by modifying *existing* transactions on demand.
>
> Ultimately bitcoin days destroyed just becomes a very complex version of
> transaction fees, and it's already well known that gating blocksize on
> total transaction fees doesn't work.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000f53e2d214685abf15b6d62d32453a03b0d472e374e10e94
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/50484235/attachment.html>

2023-06-07 15:33:55 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:Matt,
It seems you missed my suggestion about basing the maximum block size on
the bitcoin days destroyed in transactions that are included in the block.
I think it has potential for both scaling as well as keeping up a constant
fee pressure. If tuned properly, it should both stop spamming and increase
block size maximum when there are a lot of real transactions waiting for
inclusion.
- Joel
On Fri, May 8, 2015 at 1:30 PM, Clément Elbaz <clem.ds at gmail.com> wrote:
> Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my
> favorite.
>
> I see two problems with proposal #2.
> The first problem with proposal #2 is that, as we see in democracies,
> there is often a mismatch between the people conscious vote and these same
> people behavior.
>
> Relying on an intentional vote made consciously by miners by choosing a
> configuration value can lead to twisted results if their actual behavior
> doesn't correlate with their vote (eg, they all vote for a small block size
> because it is the default configuration of their software, and then they
> fill it completely all the time and everything crashes).
>
> The second problem with proposal #2 is that if Gavin and Mike are right,
> there is simply no time to gather a meaningful amount of votes over the
> coinbases, after the fork but before the Bitcoin scalability crash.
>
> I like proposal #1 because the "vote" is made using already available
> data. Also there is no possible mismatch between behavior and vote. As a
> miner you vote by choosing to create a big (or small) block, and your
> actions reflect your vote. It is simple and straightforward.
>
> My feelings on proposal #3 is it is a little bit mixing apples and
> oranges, but I may not seeing all the implications.
>
>
> Le ven. 8 mai 2015 à 09:21, Matt Whitlock <bip at mattwhitlock.name> a
> écrit :
>
>> Between all the flames on this list, several ideas were raised that did
>> not get much attention. I hereby resubmit these ideas for consideration and
>> discussion.
>>
>> - Perhaps the hard block size limit should be a function of the actual
>> block sizes over some trailing sampling period. For example, take the
>> median block size among the most recent 2016 blocks and multiply it by 1.5.
>> This allows Bitcoin to scale up gradually and organically, rather than
>> having human beings guessing at what is an appropriate limit.
>>
>> - Perhaps the hard block size limit should be determined by a vote of the
>> miners. Each miner could embed a desired block size limit in the coinbase
>> transactions of the blocks it publishes. The effective hard block size
>> limit would be that size having the greatest number of votes within a
>> sliding window of most recent blocks.
>>
>> - Perhaps the hard block size limit should be a function of block-chain
>> length, so that it can scale up smoothly rather than jumping immediately to
>> 20 MB. This function could be linear (anticipating a breakdown of Moore's
>> Law) or quadratic.
>>
>> I would be in support of any of the above, but I do not support Mike
>> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the
>> road without actually solving the problem, and it does so in a
>> controversial (step function) way.
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150508/b6a95d5e/attachment.html>

2023-06-07 15:29:18 UTC

- reply

📅 Original date posted:2015-02-02
📝 Original message:If the attacker has your desktop computer but not the mobile that's acting
as an independent second factor, how are you then supposed to be able to
tell you're not signing the correct transaction on the mobile? If the
address was replaced with the attacker's address, it'll look like
everything is ok.
- Joel
On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi <brian.erdelyi at gmail.com>
wrote:
>
> > Confusing or not, the reliance on multiple signatures as offering
> greater security than single relies on the independence of multiple
> secrets. If the secrets cannot be shown to retain independence in the
> envisioned threat scenario (e.g. a user's compromised operating system)
> then the benefit reduces to making the exploit more difficult to write,
> which, once written, reduces to no benefit. Yet the user still suffers the
> reduced utility arising from greater complexity, while being led to believe
> in a false promise.
>
> Just trying to make sure I understand what you’re saying. Are you eluding
> to that if two of the three private keys get compromised there is no gain
> in security? Although the likelihood of this occurring is lower, it is
> possible.
>
> As more malware targets bitcoins I think the utility is evident. Given
> how final Bitcoin transactions are, I think it’s worth trying to find
> methods to help verify those transactions (if a user deems it to be
> high-risk enough) before the transaction is completed. The balance is
> trying to devise something that users do not find too burdensome.
>
> Brian Erdelyi
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> 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/20150202/c75f7707/attachment.html>

2023-06-07 10:09:19 UTC

- reply

📅 Original date posted:2012-05-24
📝 Original message:I think the strong verification would go well if you add it along with an
optimization that avoids rechecking transactions that have already been
verified as valid. Any transactions it doesn't have to verify are from the
pool, of course :)
On Thu, May 24, 2012 at 7:33 PM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block < X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
>
> The former is easier to implement, though there is the danger that
> no-TX miners simply include a statically generated transaction or two.
>
> The latter might be considered problematic, as it might refuse to
> relay quickly found blocks.
>
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120524/736e9b6b/attachment.html>

2023-06-07 02:50:42 UTC

- reply

📅 Original date posted:2011-12-22
🗒️ Summary of this message: Nodes joining a network have low cost, but not checking transactions can lead to faulty work, making it important to know which nodes are checking.
📝 Original message:On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
> Why should they have to? Joining the network as a node is very low cost to
> the other nodes. You can't force any node not to be lazy, since their option
> is to disconnect themselves. As to maliciousness, that is defended against
> because when a node negative announces a transaction, that transaction is
> going to be checked (note that there is still no implicit trust) -- if a node
> is incorrectly negative-announcing then it can justifiably be kicked.
a node that is not doing any checking themselves can not reliably
forward failed verifications without getting the blame for doing faulty
work. Those nodes would then have the incentive not to relay the failed
verifications. This ends up making it important to know which nodes will
be checking transactions or not so you don't isolate yourself from other
nodes that are also checking transactions.
- Joel

2023-06-07 02:46:41 UTC

- reply

📅 Original date posted:2011-12-14
🗒️ Summary of this message: A discussion about the validity of a URI for sending Bitcoin to a recipient's address, with one participant arguing it doesn't have to be valid.
📝 Original message:On Wed, 2011-12-14 at 15:07 -0500, Luke-Jr wrote:
> > "Sure, send it to david.bitcoin.se".
>
> That's not a valid URI.
I realize I'm responding to an useless nitpick with another useless
nitpick but here goes.
It doesn't have to be a valid URI. As long as the recipient (or the
software he's using) can make it into a valid URI. My web-browser
definitely would open http://david.bitcoin.se/ from that. For bitcoin
clients, https:// should be the guess it tries.
- Joel

2023-06-07 02:11:37 UTC

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: Bitcoin resends wallet transactions with zero confirmations, and both sent and received transactions fall within the "wallet tx" superset. UDP packets with spoofed sender addresses are interesting, but unreliable. TCP over UDP is possible with UTP.
📝 Original message:On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote:
> Yes, that is correct. Bitcoin resends wallet transactions with zero
> confirmations, and both sent and received transactions fall within the
> "wallet tx" superset.
>
> TBH I had forgotten about the resend on the receiver side, though.
> It, of course, makes plenty of sense in the context of importing
> transactions from foreign sources, e.g. receiving transactions via a
> USB flash drive.
Could every node do the resends? Alternatively, could we implement a TOR
like tunneling system just for the first leg of the transactions
(overkill?). Then again, maybe just a TOR gateway if that's desired.
> > Drawok's suggestion about using UDP packets with spoofed sender addresses is
> > interesting, as UDP has another advantage; you can open up an "inbound" UDP
> > port on almost any NAT router without any UPNP magic: just send out an UDP
> > packet, the router will wait a certain time for answers (on a mapped port
> > number) and relay these back.
This is a nice idea but sounds rather unreliable.
> Well, it -is- possible to implement TCP over UDP <grin> The TCP
> connection sequence over UDP helps to work against spoofing, while UDP
> helps to open an inbound UDP port as you describe.
There's already an implementation of this, called UTP. If we do decide
that using UDP is worthwhile, this library is probably better than
implementing something ourselves.
- Joel

2023-06-07 02:08:45 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Discussion on implementing bug bounties for Bitcoin development, with suggestions for a more democratic approach and hiring a full-time developer.
📝 Original message:When I first found bitcoin, I was a bit surprised there were no paid by
community developers working on it. However, the bounties would be a
more democratic way of guiding the progress as well as allow things to
happen without a stable flow of money.
Having said that, if it's feasible, having someone hired full time to
work on the software would be great. I'm too much of a newcomer myself
to be able to provide any financial support for that though. I could
most likely contribute towards some bug bounties but if there was a bug
I'd want to offer bounty for, I'd be fixing it myself already.
- Joel
On Wed, 2011-07-27 at 09:07 -0700, Rick Wesson wrote:
> personally, if the software works better (less bugs) then btc will be
> more valuable. offering bounty is orthorginal to finding the right
> technical lead that will hurd the effort.
>
>
> put a bounty (salary) on the person to lead the effort, not the bugs
>
>
> -rick
>
>
> On Wed, Jul 27, 2011 at 7:28 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, July 27, 2011 10:20:07 AM John Smith wrote:
> > On Wed, Jul 27, 2011 at 11:14 AM, Joel Joonatan Kaartinen
> > <joel.kaartinen at gmail.com> wrote:
> > > Perhaps even add a way for anyone add to the bounty
> attached to a bug on
> > > the bug tracker? Also, a listing page for bugs with their
> bounties might
> > > be nice too.
> >
> > Good idea. I'm not sure if the github bug tracker supports
> extension
> > attributes, but it'd be a great place to add it. Also,
> people can let know
> > that they're already working on a feature using a comment,
> to prevent
> > double work.
>
>
> I'm not sure a few small bounties would justify agreeing to
> GitHub's steep
> demand for potentially unlimited money in their terms of
> service...
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help
> often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________ Bitcoin-development mailing list Bitcoin-development at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:08:26 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Proposal to add a bounty feature to GitHub's bug tracker. Concerns raised about agreeing to GitHub's TOS and potential need for a separate bug tracker.
📝 Original message:As it's unlikely to be an automated system anyway, I do not see why
people claiming the bounties would need to agree with the GitHub TOS.
Besides which, I suspect most people contributing to bitcoin already
have agreed to it.
Although, if GitHub can't support the feature, it could be an argument
for setting up a bug tracker unrelated to GitHub.
- Joel
On Wed, 2011-07-27 at 10:28 -0400, Luke-Jr wrote:
> On Wednesday, July 27, 2011 10:20:07 AM John Smith wrote:
> > On Wed, Jul 27, 2011 at 11:14 AM, Joel Joonatan Kaartinen
> > <joel.kaartinen at gmail.com> wrote:
> > > Perhaps even add a way for anyone add to the bounty attached to a bug on
> > > the bug tracker? Also, a listing page for bugs with their bounties might
> > > be nice too.
> >
> > Good idea. I'm not sure if the github bug tracker supports extension
> > attributes, but it'd be a great place to add it. Also, people can let know
> > that they're already working on a feature using a comment, to prevent
> > double work.
>
> I'm not sure a few small bounties would justify agreeing to GitHub's steep
> demand for potentially unlimited money in their terms of service...
>

2023-06-07 02:08:16 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Suggestion to offer BTC bounties for fixing bugs on the bug tracker to encourage more bug-fixing and testing of existing functionality.
📝 Original message:Perhaps even add a way for anyone add to the bounty attached to a bug on
the bug tracker? Also, a listing page for bugs with their bounties might
be nice too.
- Joel
On Wed, 2011-07-27 at 06:40 +0000, John Smith wrote:
>
> On Wed, Jul 27, 2011 at 1:31 AM, Gavin Andresen
> <gavinandresen at gmail.com> wrote:
> Anybody have advice on how to encourage more bug-fixing and
> testing of existing functionality instead of
> yet-more-features?
>
> Make a list of bugs. Offer BTC bounties for fixing each one according
> to how serious/difficult it is. They don't have to be high, just a few
> BTC. It'll also help people get interested in the project and
> *current* source base (instead of wanting to implement Yet Another
> Incomplete Client from scratch).
>
> Or we could do the same as the mozilla/chrome projects, offer bounties
> for finding new security holes and serious bugs.
>
> A policy like "that spiffy new feature you want won't be considered
> until you've helped close some open bugs" won't work. This is open
> source, people can just make their own fork with the spiffy new
> feature without fixing any bugs.
>
> JS
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________ Bitcoin-development mailing list Bitcoin-development at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development