<unnamed>

Public Key

npub1g97v5rt5sguagjk0cetckrhhmr3hded8u4vwe5keqphe7ye9tgfsv323pl

Profile Code

nprofile1qqsyzlx2p46gyww5ft8uv4utpmma3cmkukn72k8v6tvsqmulzvj45ycprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsdwny27

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:42:02 UTC

- reply

📅 Original date posted:2015-10-07
📝 Original message:On Monday, October 5, 2015, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As Greg explained to you repeatedly, a softfork won't cause a
>> non-upgraded full node to start accepting blocks that create more
>> subsidy than is valid.
>>
>
> It was an example. Adam Back's extension blocks proposal would, in fact,
> allow for a soft forking change that creates more subsidy than is valid (or
> does anything else) by hiding one block inside another.
>
Maybe I'm missing something, but wouldn't this turn into a hard fork the
moment you try to spend an output created in one of these extension blocks?
So sure, the block that contains the extension would be considered valid,
but unupgraded validators will not update the UTXO set accordingly, meaning
that those new TXOs can't be spent because, according to their rules, they
don't exist.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151007/a86d8d32/attachment-0001.html>

2023-06-07 17:36:38 UTC

- reply

📅 Original date posted:2015-08-18
📝 Original message:A smaller block size would make this a soft fork, as unupgraded nodes would
consider the new blocks valid. It would only make things that were allowed
forbidden, which is the definition of a soft fork. For a hard fork, you
need to allow something that was previously invalid.
On Tuesday, August 18, 2015, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all
> types of technology has since improved by >50%. I don't mind making it a
> bit smaller but in that case not much valuable data could be gathered and
> the second objective of this experiment may not be archived.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/e459cb0b/attachment-0001.html>

2023-06-07 17:35:42 UTC

- reply

📅 Original date posted:2015-08-18
📝 Original message:My interpretation is that he's saying Satoshi wouldn't be welcome to return
as Satoshi, because whatever he did/said would inevitably end up being
treated with authority, which shouldn't be the case.
On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I honestly don't understand your position, but I get the sense that you
> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
> active in development again?
>
> Warren
> On Aug 17, 2015 1:38 PM, "Oliver Egginger" <bitcoin at olivere.de
> <javascript:_e(%7B%7D,'cvml','bitcoin at olivere.de');>> wrote:
>
>> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
>> > This bitcoin-dev list restarted with an empty subscriber list on June
>> > 21st, 2015. So whoever posted from satoshi at vistomail.com
>> <javascript:_e(%7B%7D,'cvml','satoshi at vistomail.com');>
>> > <mailto:satoshi at vistomail.com
>> <javascript:_e(%7B%7D,'cvml','satoshi at vistomail.com');>> subscribed and
>> verified the address
>> > recently. Do you propose that we manually approve new subscribers to
>> > prevent these kind of "abuses" as you put it?
>>
>> I would simply block the creators old email addresses. Easy with
>> Mailman. I thought that would be a good and easy approach, but maybe I'm
>> wrong.
>>
>> Some believes it is possible that the email could be genuine. Some say
>> that only the content is important. I have closely followed. An
>> interesting discussion. Thank you all so far.
>>
>> But let's say the poster would be the real Satoshi. Would we discuss his
>> posting if he would not claim to be Satoshi? There are a lot of smart
>> people on this list, which publish occasionally quite useful ideas. But
>> much of this is hardly the subject of greater discussion. Especially not
>> when it comes to the blocksize. On this subject almost everything has
>> been already said. But not yet by everyone. Especially not by Satoshi.
>>
>> Satoshi would have a decisive influence on the community. I'm sure. To
>> say it does not matter who's talking is maybe genteelly but a little bit
>> remote from everyday life. Or not? Satoshi is the creator. What he says
>> is in the newspaper and is perceived by all. If he says it's okay to do
>> nothing as long as we stand together, then people have the courage to do
>> maybe something dangerous or something wrong. Then people only follow
>> their hearts. Otherwise they follow their fear. It is a paradox of the
>> human nature that some type of Dictatorship can make you free. I say
>> some type, not any type. Enough said.
>>
>> - oliver
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/1cbd3418/attachment.html>

2023-06-07 17:35:14 UTC

- reply

📅 Original date posted:2015-08-15
📝 Original message:If this proposal has less than half of the total hashpower (or is it even
less than 75%? Haven't quite thought it through completely) supporting it,
I can see the following happening if the sum of supporters and people who
want to screw the supporters out of money is at least 75%:
Non-supporters create blocks with the new version, but don't actually
implement the rule. Then after the new rule is locked in, miners will
create too-large blocks that are rejected by the majority. If the
percentage is less than half, then from their perspective, they will
essentially be on the losing side of a soft fork, and they'll be losing
money by mining for nothing, even from their perspective and that of e.g.
users and merchants who have upgraded.
On Saturday, August 15, 2015, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> So if you want a user vote, that's an issue that'd have to be tackled:
>> the people who admin the main communication channels Bitcoin users have
>> vowed to censor any program that doesn't slavishly follow 51%+ hash
>> power. That attempt to control the conversation is certainly not
>> libertarian or democratic in nature, but there you go.
>>
>
> These types of actions are immediately apparent to anyone who looks at the
> Bitcoin ecosystem (Bitcoin.org, Githib, Wiki, bitcointalk, etc.) and were
> readily apparent long before any block size debate. It is almost a taboo
> subject and anyone who raises these types of issues is immediately labeled
> as a "troll." These are the people who used to run around saying that
> Bitcoin development is "decentralized" because anyone can fork the code and
> now many of the same people claim a fork will destroy everything.
>
> The problem is that a small group of highly irrational and inexperienced
> people (outside of the small and unusual Bitcoin ecosystem) have control
> over the majority of the resources. I think over time the problem will
> even itself out but currently it is an obstacle in moving Bitcoin forward.
>
> Russ
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/65208c23/attachment.html>

2023-06-07 15:47:26 UTC

- reply

2023-06-07 15:47:04 UTC

- reply

2023-06-07 15:41:34 UTC

- reply

📅 Original date posted:2015-07-06
📝 Original message:On Monday, July 6, 2015, Dan Bryant <dkbryant at gmail.com> wrote:
> On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> > This is called child pays for parent and there is a three year old pull
> > request implementing it:
> >
> > https://github.com/bitcoin/bitcoin/pull/1647
>
> Understood... When I wrote the BIP proposal I was assuming
> (incorrectly) that CPFP TX selection was already being done by miners,
> but I see now that certain trees could bloom the TX selection latency
> as miners would need to be more dependency aware. Perhaps the BIP66
> orphan block chain shows that some miners may not always be counted on
> to ensure that all TX stuffed in a block have dependencies met.
> Certainly not until the PR1647 is fully merged and deployed.
>
> On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock <bip at mattwhitlock.name
> <javascript:;>> wrote:
> > PR#1647 only addresses miner policy, though, right? I believe the BIP is
> > addressing the user-facing side of this functionality. CPFP mining policy
> > does very little good if wallets don't offer any way for users to goose
> up
> > incoming transactions.
>
> On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> > The points regarding sweep transaction UI is out of scope for a BIP I'm
> > afraid. I suggest talking with wallet authors, and if agreement can be
> > found writing a pull request.
>
> Yes... although I certainly admit, I didn't know about CPFP or I would
> have called it out as a requirement for this UI enhancement request.
> I'll see if I can't get some wallet authors interested in this as a
> feature enhancement when PR1647 commits.
>
> Perhaps there are risks raised if CPFP is not enabled but these sweep
> tx enter the mempool. If miners take the high fee "children" but
> ignore the low fee "parents" then the child might enter the blockchain
> without the parent. If miners were light on block validation,
> wouldn't it be possible that the child may go forward with many
> confirmations, while the parent patiently waits in the mempool? This
> could be bad since spending the child may look good, as it might have
> many confirmations, while its parent has few.
A child is a transaction that spends outputs of another transaction, the
parent. The child cannot be confirmed before the parent, because the
outputs being spent do not yet exist.
>
> On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <pete at petertodd.org
> <javascript:;>> wrote:
> > "Replace-by-fee scorched-earth without child-pays-for-parent",
> > Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html
>
> Very good! So if I follow, RPF can work one of two ways:
>
> In the "countermeasure" form, spender gives receiver a partially
> signed "countermeasure" transactions with juiced up fees.
>
> In the "anyonecanpay" form, spender signs the transaction with
> ANYONECANPAY bit allowing the reviver to add fees at will.
>
> One question I did have about RBF is this.. Is it correct to presume
> that the spender doesn't send the incomplete "countermeasure"
> transaction to the network? If they did, wouldn't they get flagged on
> DoS code banning them from peers?
A transaction that is not completely signed won't be relayed, correct, and
it cannot be mined.
> Corollary question. If the "countermeasure" transaction is not
> broadcast, is it sent to the receiver via back channel (email, etc)
>
> I'll try to clean up the draft BIP to include CPFP dependencies and
> RBF capabilities. Whether it belongs in a BIP or a PR, its just a doc
> to outline my thoughts at this point. Not burning a whole in my head,
> so may take some time.
>
> Thx.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <javascript:;>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150706/8c82606a/attachment.html>