Joel Joonatan Kaartinen [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-07-27 to 2015-05-08
💬 Posted a total of 20 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrx

Profile Code

nprofile1qqsd22smwf23hwj8h6c5vwdpkm67dnvcvqlvh24x4vpqx9cgm8xygucnh6pfy

Author Public Key

npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrx

Show more details

Last Notes

2023-06-07 15:33:56

- 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

- 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:33:21

- reply

📅 Original date posted:2015-05-07
📝 Original message:Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn't feel right when it takes ages to
burn through the backlog when 100% full is hit for a while. So, while
pondering this, I got an idea that I think has a chance of working that I
can't remember seeing suggested anywhere.
How about basing the maximum valid size for a block on the total bitcoin
days destroyed in that block? That should still stop transaction spam but
naturally expand the block size when there's a backlog of real
transactions. It'd also provide for an indirect mechanism for increasing
the maximum block size based on fees if there's a lot of fees but little
bitcoin days destroyed. In such a situation there'd be incentive to pay
someone to spend an older txout to expand the maximum. I realize this is a
rather half baked idea, but it seems worth considering.
- Joel
On Thu, May 7, 2015 at 10:31 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> This *is* urgent and needs to be handled right now, and I believe Gavin
> has the best approach to this. I have heard Gavin's talks on increasing
> the block size, and the two most persuasive points to me were:
>
> (1) Blocks are essentially nearing "full" now. And by "full" he means
> that the reliability of the network (from the average user perspective) is
> about to be impacted in a very negative way (I believe it was due to the
> inconsistent time between blocks). I think Gavin said that his simulations
> showed 400 kB - 600 kB worth of transactions per 10 min (approx 3-4 tps) is
> where things start to behave poorly for certain classes of transactions.
> In other words, we're very close to the effective limit in terms of
> maintaining the current "standard of living", and with a year needed to
> raise the block time this actually is urgent.
>
> (2) Leveraging fee pressure at 1MB to solve the problem is actually really
> a bad idea. It's really bad while Bitcoin is still growing, and relying on
> fee pressure at 1 MB severely impacts attractiveness and adoption potential
> of Bitcoin (due to high fees and unreliability). But more importantly, it
> ignores the fact that for a 7 tps is pathetic for a global transaction
> system. It is a couple orders of magnitude too low for any meaningful
> commercial activity to occur. If we continue with a cap of 7 tps forever,
> Bitcoin *will* fail. Or at best, it will fail to be useful for the vast
> majority of the world (which probably leads to failure). We shouldn't be
> talking about fee pressure until we hit 700 tps, which is probably still
> too low.
>
> You can argue that side chains and payment channels could alleviate this.
> But how far off are they? We're going to hit effective 1MB limits long
> before we can leverage those in a meaningful way. Even if everyone used
> them, getting a billion people onto the system just can't happen even at 1
> transaction per year per person to get into a payment channel or move money
> between side chains.
>
> We get asked all the time by corporate clients about scalability. A limit
> of 7 tps makes them uncomfortable that they are going to invest all this
> time into a system that has no chance of handling the economic activity
> that they expect it handle. We always assure them that 7 tps is not the
> final answer.
>
> Satoshi didn't believe 1 MB blocks were the correct answer. I personally
> think this is critical to Bitcoin's long term future. And I'm not sure
> what else Gavin could've done to push this along in a meaninful way.
>
> -Alan
>
>
>
> On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that people
>> must find and alternative right now. Quite a lot here do not believe there
>> is any urgency, nor that there is an immanent problem that has to be solved
>> before the sky falls in.
>>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all over
> again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> 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 listBitcoin-development at lists.sourceforge.nethttps://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/fa4f0644/attachment.html>

2023-06-07 15:29:18

- 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:34:28

- reply

📅 Original date posted:2012-10-04
📝 Original message:For script evaluation benchmarking, I don't think just a good
approximation of real-world traffic is enough. You really need to
benchmark the worst case scenarios, otherwise you could be creating a
DoS vulnerability.
- Joel
ke, 2012-10-03 kello 13:57 -0400, Ian Miers kirjoitti:
> Script evaluation performance was what I was primarily concerned
> with. I'm fooling around with adding some new instruction types.
> The tricky part is that to test how that effects performance, you need
> to be able to intersperse transactions with the new instructions with
> existing ones. For accuracy, you'd like your simulated traffic to at
> least approximate the real world traffic.
>
>
>
>
> Also, is there any bench-marking / instrumentation in bitcoind ?
>
>
> Ian
> On Wed, Oct 3, 2012 at 1:43 PM, Jeff Garzik <jgarzik at exmulti.com>
> wrote:
> On Wed, Oct 3, 2012 at 1:38 PM, Ian Miers <imiers1 at jhu.edu>
> wrote:
> > Whats the best way to get performance numbers for
> modifications to bitcoin ?
> > Profiling it while running on testnet might work, but that
> would take a
> > rather long time to get data.
> > Is there anyway to speed this up if we only needed to
> provide relative
> > performance between tests. (in a sense a fast performance
> regression test).
>
>
> You have to be specific about what you're measuring, because
> "performance" is vague.
>
> You can measure many aspects of blockchain performance by
> importing
> blocks via -loadblock=FILE.
>
> Other performance measurements like "how fast does a block
> relay
> through the network" cannot be as easily measured.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________ Bitcoin-development mailing list Bitcoin-development at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:09:19

- 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:53:18

- reply

📅 Original date posted:2011-12-31
🗒️ Summary of this message: Proposal to restrict the number of executions of OP_EVAL per transaction to prevent unlimited looping and consider transactions with too many executions illegal.
📝 Original message:Wouldn't it work to restrict the number of executions of OP_EVAL allowed
per transaction? That way it wouldn't allow for unlimited looping. If
there's too many OP_EVAL executions during the transaction evaluation,
just consider the transaction illegal. 3 would be enough for the
purposes people have been planning for here I think.
- Joel
On Thu, 2011-12-29 at 11:42 -0500, roconnor at theorem.ca wrote:
> On Thu, 29 Dec 2011, theymos wrote:
>
> > On Thu, Dec 29, 2011, at 01:55 AM, roconnor at theorem.ca wrote:
> >> The number of operations executed is still bounded by the number of
> >> operations occurring in the script. With the OP_EVAL proposal the
> >> script language becomes essentially Turing complete, with only an
> >> artificial limit on recursion depth preventing arbitrary computation
> >> and there is no way to know what code will run without executing it.
> >
> > Even if OP_EVAL allowed infinite depth, you'd still need to explicitly
> > specify all operations performed, since there is no way of looping.
>
> That's not true. Gavin himself showed how to use OP_EVAL to loop:
> OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL.
>
> Basically OP_DUP lets you duplicate the code on the stack and that is the
> key to looping. I'm pretty sure from here we get get Turing completeness.
> Using the stack operations I expect you can implement the SK-calculus
> given an OP_EVAL that allows arbitrary depth.
>
> OP_EVAL adds dangerously expressive power to the scripting language.
>

2023-06-07 02:50:42

- 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

- 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:41:30

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: Discussion on the "I got lucky and found an extremely hard block" problem in Bitcoin, and a potential solution using an upper bound on difficulty.
📝 Original message:On Wed, 2011-11-23 at 15:39 +0000, Andy Parkins wrote:
> On 2011 November 23 Wednesday, Gavin Andresen wrote:
>
> > Bitcoin as-is doesn't have the "I got lucky and found an extremely
> > hard block" problem because the difficulty TARGET is used to compute
> > chain difficulty, not the actual hashes found.
>
> Good points. I don't think I have a response to that one.
If there's an upper bound on the difficulty a block is accepted to have
(even if it would've passed with significantly higher difficulty), that
could solve this issue. For example, take the median (or average) of the
past 2016 blocks and don't value any new block for more than maybe 4
times as difficult as that.
> I saw the "I got lucky" result as a benefit, as it made it harder to fork the
> chain. We got an advantage from the luck.
>
> I'll have to abandon this suggestion. It's not going to work.
>
> Thanks for the feedback everyone.
Don't be so hasty with that :)
- Joel

2023-06-07 02:38:35

- reply

📅 Original date posted:2011-11-09
🗒️ Summary of this message: Creating a separate P2P network for off-band information is better than involving the blockchain, as miners could remove extra scriptSig information.
📝 Original message:It's propably best to create a separate p2p network for off-band
information like this. No need to involve the blockchain with it.
- Joel
On Wed, 2011-11-09 at 16:18 -0500, Gavin Andresen wrote:
> One more thought on putting arbitrary stuff in the scriptSig:
>
> Miners could decide to revolt and remove the extra scriptSig
> information before including the transaction in their blocks. They'd
> still get the full transaction fee, and the transaction would still
> validate so the block would be accepted by everybody else.
>
> Come to think of it, if a node relaying transactions wanted to save
> bandwidth costs or be annoying, it could also strip off the extra
> information before forwarding it, so this isn't a reliable
> communication mechanism. It is probably a much better idea to use
> another protocol to gather signatures.
>

2023-06-07 02:35:14

- reply

📅 Original date posted:2011-10-25
🗒️ Summary of this message: The author proposes two options for implementing green transactions, with the first being a quick hack and the second being a more proper solution. There is controversy surrounding green transactions and a peer-sourced implementation is suggested.
📝 Original message:On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote:
> 1) Get something working reasonable fast to detect current green address
> style transactions. It's fine if it is a little bit of a hack, as long as
> it's safe, since I don't expect it to be merged with mainline anyway at
> this point.
>
> 2) Rethink how green transactions are created and verified and try to put
> something 'proper' together which has a chance of being merged at some
> point.
>
> For the moment I was going more with 1) because I got the impression, that
> green transactions are too controversial at this point to get them
> included in mainline. Criticism ranging from 'unnecessary, as
> 0-confirmation transactions are fairly safe today' to 'encourages too much
> centralization and therefore evil'. So how to people on this list feel
> about green transactions? Would people be interested in helping me with
> 2)?
One possibility would be to create a peer sourced green address
implementation. That is, each user could, individually decide to trust
certain addresses as "green" and optionally, publish this trust. Basing
things on the published trust, you could dynamically, as opposed to
static hierarchies, evaluate the trustworthiness of each green address
you haven't personally decided to trust.
This would be somewhat involved implementation, though, as it would
require heavy statistical calculations.
- Joel

2023-06-07 02:26:58

- reply

📅 Original date posted:2011-09-16
🗒️ Summary of this message: Failing hard is better for Bitcoin's protection as it immediately notifies users of the problem, while failing soft may increase the risk of network splitting.
📝 Original message:> Darn good question. If the protection fails, would it be better for it
> to 'fail hard', leaving people complaining "bitcoin won't stay
> connected!"
>
> Or fail soft, so you at least have a couple of connections.
>
> I think fail hard is better-- we'll immediately know about the
> problem, and can fix it. Fail soft makes me nervous because I think
> that would make it more likely a bug splits the network (and,
> therefore, the blockchain).
My own preference would be to fail hard with detection of the problem
and notification of the user if there's a GUI connected and/or running.
- Joel

2023-06-07 02:16:25

- reply

📅 Original date posted:2011-08-18
🗒️ Summary of this message: The lessons from a Bitcoin attack are to not accept 1-confirmation transactions and to be well-connected, but also to not trust information from only one peer.
📝 Original message:On Thu, 2011-08-18 at 10:00 -0400, Gavin Andresen wrote:
> The lessons are "don't accept 1-confirmation transactions" and "try
> to be well-connected."
>
> But maybe the deeper lesson is "don't trust information you get from
> only one peer." Or maybe "watch for peers that are trying to fool
> you."
This particular attack seems quite dependant on the target not using the
deposit Tx as input. I believe this whole class of attacks become
ineffective if each account has it's own separate wallet.
Also, receiving a block with a transaction that hasn't been broadcast to
the network is in itself quite suspect. Are there cases where that
happens legitimately? Perhaps in such a case, don't treat the block it
came in as a confirmation at all. Instead, start counting from the next
one.
- Joel

2023-06-07 02:14:29

- reply

📅 Original date posted:2011-08-11
🗒️ Summary of this message: A developer suggests that the Bitcoin community needs to be more open to breaking changes, or risk a fork in the network. They propose a wiki section for recording past suggestions.
📝 Original message:On Thu, 2011-08-11 at 06:47 +0100, Andy Parkins wrote:
> Again you're missing my point... you are still shooting ideas down.
And you're only shooting his actions down without indicating clearly
what you think ought to be done instead. What do you want him to say
instead?
> > community also seems rather hard-wired against breaking changes like
> > that, because it implies that we lowly dev peons are daring to mess
> > with the Blessed Satoshi Design that has received extensive study, and
> > 100% communal agreement.
>
> Well the community had better unhardwire itself or its going to end up with
> five developers and no more.
No way that will happen. A fork is going to happen sooner rather than
later if this continues. It'd be great if it could be done within this
project and named bitcoin-dev or bitcoin-next or similar.
If this is not done, I wouldn't be surprised with the network splitting
into 2 camps with different protocols but still working on the same
blockchain.
> > If the community changes its mind, and there are strong calls to make
> > a breaking change, we can certainly do that. Bitcoin is not only open
> > source but very much democratic -- people vote by choosing which
> > client software to use.
>
> Voting with ones feet should be a last resort. Wouldn't it be better not to
> end up with incompatible clients out there?
There's no way to get the majority to vote with their feet to move to an
incompatible client. Not immediately anyway. It can happen gradually
though.
As in: 1) alternative client is published that is compatible but
extended. 2) this client gets the majority share of users/miners 3) they
see this and decide to break compatibility. 4) original bitcoin client
is now incompatible/history.
> > It's negative to weight costs vs. benefits? That is what I expect any
> > good engineer to do.
>
> I don't think that's what's happening. Not once have I seen the "benefits"
> side of that equation. What I have seen is plenty of "I can't see a use
> case for that"; when the key word in that sentence is "I".
What is happening here is that most suggestions you point at have been
discussed about before and so the "early adopter" developers remember
that a decision about that was made already. However, the problem here
lies with the fact that it's difficult to find the previous
conversations.
If there was a section in the wiki for recording past suggestions, there
would be no need to say 'no'. You could instead say "We have discussed
this before, please read..." and give them a link to the page with the
relevant discussion. Of course, this would require actively forwarding
people to the wiki for discussions and having them there. I think this
would be a good idea.
That would leave this list for discussing and coordinating the
implementation of the changes that have been agreed on.
For things that have already been discussed, you could try to find the
previous discussion and add it there. But I expect for some things, new
discussion needs to be had to get it on the wiki.
- Joel

2023-06-07 02:11:37

- 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:51

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: A developer expresses concern about sharing progress on a tricky bug for fear of losing credit or reward, but others suggest sharing to avoid duplication.
📝 Original message:On Thu, 2011-07-28 at 08:45 +1000, Gavin Andresen wrote:
> For example, if somebody has figured out how to solve 90% of some
> tricky bug I don't want them to hesitate to ask for help on the last
> 10% because they're worried "if I describe the progress I've made so
> far somebody might swoop in and steal my bounty...."
Well, the bounty thing can't be automated, so, wouldn't publishing the
work you've done up to then by, for example, mailing this list, pretty
much guarantee someone else couldn't claim they fixed it all by
themselves anymore?
It could, however, end up with some quarrels about how much of the
bounty to give and to whom. Those are not nice things to have.
- Joel

2023-06-07 02:08:45

- 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

- 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

- 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