<unnamed>

Public Key

npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz

Profile Code

nprofile1qqs2yugavctdxj9r2s4m9fu348j3lj78klgaypjjuk47zmf7z7fjrhcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqrqyrel

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 23:20:39 UTC

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Bitcoin Core's communication issues persist, with maintainers lacking transparency on merge decisions. Bitcoin's future relies on lightning and complex changes, but simple changes could surpass Ethereum.
📝 Original message:The different emails are overlong, it's difficult to follow
It is super surprising to see that Bitcoin has only 4 maintainers funded
by Brink and Blockstream, but I think the decisions are taken elsewhere
And I think the job of the maintainers is not only to be maintainers but
to do the PR sometimes, since the process is too complicate and they are
supposed to know well the code
And it seems like bitcoin is betting its future on lightning and/or
super clever (non understandble) changes to bitcoin scripting
While some simple changes can allow bitcoin to surpass ethereum, as
usual, like "Allow several OP_RETURN in one tx and no limited size"
https://github.com/bitcoin/bitcoin/issues/27043
How long it will take remains mysterious
Le 18/04/2023 à 14:40, Michael Folkson via bitcoin-dev a écrit :
>
> Communication has been a challenge on Bitcoin Core for what I can tell
> the entire history of the project. Maintainers merge a pull request
> and provide no commentary on why they’ve merged it. Maintainers leave
> a pull request with many ACKs and few (if any) NACKs for months and
> provide no commentary on why they haven't merged it. I can only
> speculate on why and it probably depends on the individual maintainer.
> Sometimes it will be poor communication skills, sometimes it will be a
> desire to avoid accountability, sometimes it will be fear of
> unreasonable and spiteful legal action if they mistakenly merge a pull
> request that ends up containing a bug. But search through the pull
> requests on Bitcoin Core and you will rarely see a rationale for a
> merge decision. The difference between say previous maintainers like
> Wladimir and some of the current maintainers is that previous
> maintainers were extremely responsive on IRC. If you disagreed with a
> merge decision or thought it had been merged prematurely they would be
> happy to discuss it on IRC. In present times at least a subset of the
> current maintainers are not responsive on IRC and will refuse to
> discuss a merge decision. One farcical recent example [0] was the pull
> request to add Vasil Dimov as a maintainer where despite many ACKs
> from other maintainers and other long term contributors two
> maintainers (fanquake and Gloria) refused to discuss it on the pull
> request or on IRC. It took almost 5 months for Gloria to comment on
> the pull request despite many requests from me on the PR and on IRC. I
> even requested that they attend the weekly Core Dev IRC meeting to
> discuss it which they didn’t attend.
>
>
> A pull request to add a maintainer isn’t a normal pull request.
> Generally pull requests contain a lot more lines of code than a single
> line adding a trusted key. Not merging a pull request for a long
> period of time can be extremely frustrating for a pull request author
> especially when maintainers and long term contributors don’t comment
> on the pull request and the pull request is stuck in “rebase hell”.
> Clearly it is the lesser evil when compared to merging a harmful or
> bug ridden pull request but poor non-existent communication is not the
> only way to prevent this. Indeed it creates as many problems as it solves.
>
>
> Another farcical recent(ish) example was the CTV pull request [1] that
> ultimately led to a contentious soft fork activation attempt that was
> called off at the last minute. If you look at the comments on the pull
> request there were 3 individuals (including myself) who NACKed the
> pull request and I think it is fair to say that none of us would be
> considered long term contributors to Bitcoin Core. I have criticised
> Jeremy Rubin multiple times for continuing to pursue a soft fork
> activation attempt when it was clear it was contentious [3] but if you
> look at the pull request comments it certainly isn’t clear it was.
> Maintainers and long term contributors (if they commented at all) were
> gently enthusiastic (Concept ACKing etc) without ACKing that it was
> ready to merge. A long term observer of the Core repo would have known
> that it wasn’t ready to merge or ready to attempt to activate
> (especially given it was a consensus change) but a casual observer
> would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of
> these casual observers inflated the numbers on the utxos.org site [4]
> signalling support for a soft fork activation attempt.
>
>
> I set out originally to write about the controls and processes around
> merges on the default signet (bitcoin-inquisition [5]) but it quickly
> became obvious to me that if communication around Core
> merges/non-merges is this weak you can hardly expect it to be any
> better on bitcoin-inquisition/default signet where there is no real
> monetary value at stake. I will probably write about
> bitcoin-inquisition/default signet in a future email as I do think the
> perception that it is “the one and only” staging ground for consensus
> changes is dangerous [6] if the maintainer(s) on that project have the
> same inclinations as a subset of the Core maintainers.
>
>
> As I stated at the beginning there is an element to this which is not
> individual(s) specific and an adverse reaction to outright malicious
> actors external to any of these projects. I do not think any of the
> current maintainers on Core or bitcoin-inquisition are outright
> malicious even if a subset of them consistently frustrate me with
> their lack of transparency and accountability. But this issue isn't
> going away and I'm sure we'll hear more on this from others in the
> coming months. To me it is a straight choice of taking transparency
> and accountability much more seriously or failing that investing more
> heavily (time and resources) in consensus compatible forks of Core and
> treating Core like it is a proprietary "open source" project where
> merge decisions are not explained or justified in the open.
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> -- Michael Folkson Email: michaelfolkson at protonmail.com
> <http://protonmail.com/>
> Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159
> 214C FEE3
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230419/4bf67dba/attachment-0001.html>

2023-06-07 23:19:08 UTC

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: The proposed Bitcoin NFT system uses a double hash mechanism to prevent theft and counterfeiting, with a trusted third party for timestamping. A Universal Coin Swap system is also proposed.
📝 Original message:In your system what is the off-chain mechanism? And what prevent a thief
to steal your NFT?
I have submitted several time "A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
It's more simple, the NFT (whether real or electronic) is referenced by
a initial hash (which is not the hash for example of your jpeg file
because easy to fake) and then get a final reference which is the hash
of the initial hash
The idea is that the real owner must prove that he has the knowledge of
the initial hash (for example luxury bag, you print the double hash on
it, and give the initial hash to the buyer, if the owner/seller can't
prove that he knows the inital hash, the bag is stolen or counterfeit
(with the double hash))
The NFT owner references the NFT signed by him in some trusted third
party allowing a timestanp (wayback machine for example), it proves that
he is the first one to have the knowledge of the double hash, so a thief
cannot intercept the "minting" transaction (if any because not really
necessary since the public key of the owner is known from the third
party) and steal the NFT for himself or do/replay a transaction with
this NFT, minting it or selling it several time
A third party is involved but it remains decentralized
Then the NFT owner and buyer exchange some information like for
lightning and do one transaction on Bitcoin storing the deal, see the
details in the proposals depending on what kind of deal occur between
the buyer and the seller, like lightning, if someone cheats, then he
loses his bitcoin
It's minimal, understandable, secured, decentralized and not expensive,
that's why I don't see very well why to complicate with ordinals
The proposal envisions the concept of "secret" NFTs also
The continuation of this proposal is "A Universal Coin Swap system based
on Bitcoin" https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
It's simple also, you go from Decentraland to the Sandbox but don't have
SAND and want to pay with MANA, you agree on a MANA/SAND deal with the
seller which is stored in Bitcoin signed by both, then you pay with
MANA, other use cases are described in the proposal
Note: both proposals need to be modified since I thought OP_RETURN max
size was 512B and it is in fact 80B, which does not work for all cases
Le 02/02/2023 à 10:15, Anthony Towns via bitcoin-dev a écrit :
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
>
> On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
>> Briefly, newly mined satoshis are sequentially numbered in the order in
>> which they are mined. These numbers are called "ordinal numbers" or
>> "ordinals". When satoshis are spent in a transaction, the input satoshi
>> ordinal numbers are assigned to output satoshis using a simple
>> first-in-first-out algorithm.
> This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
>
> When accompanied by a standard for associating some data or right with
> such an identity, this allows the creation of non-fungible tokens (or
> semi-fungible tokens) whose ownership can be transferred by a bitcoin
> transaction.
>
> The proposed BIP doesn't document any method for associating data or a
> right with an ordinal, but the "ord" tool defines "inscriptions" to fill
> this gap [0], providing a way of including mime-encoded data in a taproot
> witness. To make such an inscription, two transactions are required:
> one paying some sats to a special scriptPubKey that commits to the
> inscribed data, and a second that spends those sats to the owner of the
> newly inscribed ordinal, and in so doing revealing the full inscription.
>
> [0] https://docs.ordinals.com/inscriptions.html
>
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
>
> [1] https://twitter.com/ajtowns/status/1619554871166013441
>
> In particular, rather than looking at it as being the owner of the sats
> that inscribes some content on those sats (analogously to signing a $100
> bill [2]), you could look at it as saying "the owner of this thing is
> whoever owns this particular sat" (eg instead of "whoever owns this
> share certificate is a shareholder", it's "whoever owns the $1 bill with
> serial number X is a shareholder").
>
> [2] https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
>
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>
> {
> "pubkey": <creator's pubkey>
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id": <hash of the above>
> "sig": <signature of id by creator's pubkey>
> }
>
> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.
>
> [3] If the satoshi was lost to fees at some point, you could continue to
> follow ownership by including an entire block in the custody chain.
> But seems better to just consider it as "abandoned" or "lost to the
> public domain" at that point.
>
> This approach allows all the "inscription" data to be entirely off-chain,
> the only thing that requires a transaction on-chain is transferring
> ownership to someone else. That allows the NFT's existance can be kept
> entirely private if desired; it also makes it cheap to create a new NFT
> (you don't need to pay any on-chain fees at all); and it doesn't impose
> an outsized overhead on people who aren't interested in your inscriptions,
> but may be interested either in bitcoin per se, or in other inscriptions.
>
> For things that have real intrinsic value -- equity rights in a company,
> bragging rights for supporting an artist, etc -- this seems like it's
> probably a viable approach: owners can "self-custody" all the information
> about the things they own without having to rely on third parties,
> transfers are no more censorable than any other bitcoin transaction
> (especially if the association of the NFT with some particular sat is
> not widely known), etc.
>
> The "inscription" approach might still be desirable for broadcasting
> information that might otherwise be subject to heavy censorship; presuming
> that the censoring entity isn't also willing and able to censor bitcoin
> itself. It's not clear that there's any "rights" to be owned for such a
> case -- you can't buy the right to be the person that first published
> it, and the point of widely broadcasting the information is so it's
> not a secret only known to a few anymore. Also, claiming ownership of
> such information would presumably make you a target for the censor,
> even if just as an example for others. So I'm dubious of the value of
> associating an inscription with an ordinal for that use case.
>
> It's also possible that the perceived value of the NFT isn't due to
> the inscription, but rather due to the scarcity of the blockspace it
> was inscribed in (eg [4]). This is different from Bitcoin's scarcity
> -- by 2100 or so there'll be a total of 2100T satoshis available,
> but in that same time there will only have been about 4T vbytes of
> blockspace available, and perhaps it could make sense to value spent
> vbytes proportionally, so 4 spent vbytes is worth 2100 sats. In that
> case if you spent 50kvb inscribing a jpeg, perhaps the "rights" to that
> jpeg should be worth the same as 50k/4*2100 sats or 0.26 BTC. Doesn't
> seem like a sound argument to me -- there's always more blockspace being
> created, by fewer and fewer sats being created, and ordinals are far more
> awkward to deal with, but I suppose it's still conceivable, and people
> at least claim to believe it. If it were true, this argument suggests
> the price for blockspace today should be around 2488sat/vB (19.28MBTC /
> 774700 MvB), rather than 1sat/vB.
>
> [4] https://twitter.com/vnprc/status/1619876888687820801
>
> Anyway, comparisons to ordinal inscriptions aside, I think there's
> another interesting point from all this.
>
> Presume you have a tool that implements the nostr ordinal assignment
> suggested above: that is, a small modification of the "ord" tool that
> can track a chain of custody for an ordinal specified in a nostr event
> like the above. That allows you to do NFTs completely unobservably --
> you don't have to publish anything to the blockchain apart from ordinary
> looking transactions to transfer ownership of your NFT. To your benefit,
> that makes it hard for anyone to censor you; but to bitcoin more broadly,
> I think it means that the possibility of coloured bitcoins is largely
> unavoidable and simply something that must be dealt with, rather than
> something we should spend time trying to prevent/avoid. Compare with:
>
>> My personal, and possibly controversial, opinion is that colored coin
>> protocols have no business being on the Bitcoin chain, possibly beyond
>> committing to an occasional batched state update or so. Both because
>> there is little benefit for tokens with a trusted issuer already, and
>> because it competes with using Bitcoin for BTC - the token that pays
>> for its security (at least as long as the subsidy doesn't run out).
>>
>> Of course, personal opinions are no reason to dictate what people should
>> or can use the chain for, but I do think it's reason to voice hesitancy
>> to worsening the system's scalability properties only to benefit what
>> I consider misguided use.
> -- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019500.html
>
> I don't think this actually results in majorly misaligned incentives
> though: in the nostr-nfts-on-btc world, everyone is still optimising
> bitcoin transactions for the same thing -- transfer of value. It's just
> that in some cases some sats are valued differently than others --
> perhaps my uninscribed sats are worth 0.025 cents each, but you have
> a particular inscribed sat that's worth $100k. But we're both dealing
> just spending utxos and creating new utxos, doing signatures and maybe
> some timelocks or hash reveals. And it's always been possible that
> your transaction transferring $100k won't get charged higher fees than
> my transfer of $50 -- we care about transaction size, not value after
> all. How much does it matter if your tx matters more to your because
> someone wants your particular sat, rather than what could happen today
> where you have a utxo with 4 BTC while my utxo only has 0.002 BTC?
>
> I think the only way to prevent that sort of NFT structure would be
> to have every transaction use fancy zero-knowledge proofs that make it
> impossible to associate who received bitcoin with who spent it -- *even
> if* both the sender and recipient were willing to cooperate to reveal
> that information. I think it would be hard to achieve that while still
> making it easy to audit bitcoin's total supply, but I might be wrong.
>
> Note that off-chain colouring here means that someone can create an NFT
> that you don't want it, and just assign it to a sat that's already in your
> wallet. However, they can do this anyway, by first creating the NFT, then
> sending it to your wallet address. A difference though is that they could
> create an NFT and assign it to the same ordinal/sat as some existing NFT
> that you do value, at which point it's (presumably) impossible to discard
> one without discarding both. But again, this is simply something they
> can do, just be writing a patch to ord and composing a nostr message;
> it's not something you can actually prevent even if you dislike it.
>
> Particularly for semi-fungible tokens, this is perhaps inferior to
> Liquid's multi-asset model -- here if you have a utxo with 1M sats, 500
> of which are inscribed to each represent rights to $1 worth of USDT,
> then rather than acting like a stable coin and being worth $500; it's
> actually worth $500+0.01BTC, which is more like $750, and changes as
> the value of bitcoin changes.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:57 UTC

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: The standard rule for OP_RETURN in Bitcoin is a maximum of 80 bytes and one output per transaction, but miners can mine non-standard transactions.
📝 Original message:Thanks, then this limitation should be rethought I think (see the email
I just sent replying to the coloured thread)
Because it forces people to store in witness (less easy to track/show I
believe) or adopt some deviant behavior (like storing in addresses where
the utxo will remain unspendable forever)
Le 02/02/2023 à 12:49, Peter Todd a écrit :
> On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote:
>> As far as I can read nobody replied to the initial question: what is
>> considered as good/best practice to store in Bitcoin?
> Your answer is beyond not putting unspendable data in the UTXO set, the exact
> details don't really matter. Do what makes sense for your specific application.
>
>> Reiterating my question: what are the current rules for OP_RETURN, max
>> size and number of OP_RETURN per tx
> Max 80 bytes, one OpReturn output per tx.
>
> This of course is the standardness rule. With a miner willing to mine non-std
> transactions anything goes.
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:57 UTC

- reply

📅 Original date posted:2023-02-03
🗒️ Summary of this message: The witness envelope is less user-friendly and more expensive than OP_RETURN. Increasing the size of OP_RETURN is a better solution for storing data.
📝 Original message:Indeed the witness envelope is more costly and less easy to use (or
read/track)
But let's take a standard P2PKH or P2WPKH output, what prevents me from
adding in the beginning of scriptSig or witness while spending it:
OP_PUSH <data> OP_DROP ? Non standard ? This one makes one transaction only
There are probably plenty of ways to store data, another one would be to
use a dummy 1 of N multisig where only 1 corresponds to a pubkey and the
rest is data, but again several transactions...
I think the right way so people don't invent deviant things is to
increase the size of OP_RETURN, I don't get this number of 80B, you can
hardly store a signature (of what?) in there and not the "what" if the
"what" is a hash for example
Le 02/02/2023 à 14:25, Rijndael via bitcoin-dev a écrit :
> Hello Christopher,
>
> I think if the protocol that you were designing always had <80 bytes,
> I'd prefer the OP_RETURN. I think the "witness envelope" has two major
> disadvantages compared to the OP_RETURN method:
>
> 1. You need to first spend to he address that commits to the script that
> encodes your data payload. So you have a two step process of first
> spending to a "commitment" address and then a second spend to "reveal"
> your payload. You can CPFP to get them both into the same block, but its
> still two transactions, so more cost, etc.
>
> 2. Because of the two step process in (1), if for some reason you were
> unable to get the "reveal" transaction into a block (for example there's
> widespread censorship of transactions that match the format of the
> "reveal" script), then you might have money that's stuck in the "commit"
> stage of the protocol. The way out of this would be to get your money
> out via the keypath or another tapleaf, but then you need to spend money
> to cancel a step in your protocol. Of course there could be widespread
> censorship of your OP_RETURNs too, but you don't have to spend funds on
> the cancellation spends.
>
> I think (2) is actually a pretty weak argument because as we saw in the
> full-rbf discussion, as long as there's some threshold number of nodes
> in the network that relay transactions to miners, you can probably find
> a path to a miner (IIRC the number was on the order of 15% of the
> network?). So I think the big reason to pick OP_RETURN over the witness
> embedding is that you save a transaction and possibly some
> failure-recovery/cancellation logic.
>
> Obviously if your data is larger than 80 bytes, then you probably want
> to do the witness-embedding method. If your data smaller, then a
> pay-to-contract tweak probably the best thing from a space and
> fingerprinting perspective.
>
> - rijndael
>
>
> On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev wrote:
>> All other things being equal, which is better if you need to place a
>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
>> spent taproot transaction such as:
>>
>> OP_FALSE
>> OP_IF
>> OP_PUSH my64bytes
>> OP_ENDIF
>>
>> I know that the anti-OP_RETURN folk would say “neither.” But if there
>> was no other choice for a particular protocol, such as a timestamp or
>> a commitment, which is better? Or is there a safer place to put 64
>> bytes that is more uncensorable but also does not clog UTXO space,
>> only spent transaction `-txindex` space?
>>
>> My best guess was that the taproot method is better, but I suspect
>> there might be some who disagree. I'd love to hear all sides.
>>
>> -- Christopher Allen
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:57 UTC

- reply

📅 Original date posted:2023-02-01
🗒️ Summary of this message: The debate is on the standard for OP_RETURN in Bitcoin, with data limited to 80B and only one allowed per transaction, leading to storage workarounds. Some suggest using spent taproot transactions instead.
📝 Original message:Could someone clarify what is the standard for OP_RETURN? As far as I
understand the data is limited to 80B and only one OP_RETURN is allowed
in one transaction, if not the tx is non standard, correct?
Then the debate can be to store in witness indeed
Or you can store in output addresses (with super big size), then you
will never be able to spend the dust and we have a utxo forever
In any case there is a storage workaround, probably others exist, not
sure why people are so opposed to a OP_RETURN bitcoin storage (I thought
the max size was 512B, but apparently I am wrong, 80B is ridiculous,
can't do anything with this, except bypassing this limit by other worse
means)
Storage is the main difference between bitcoin and other systems
(ethereum), without it, repeating myself here again the future of
bitcoin is very limited
PS: I saw the answer of Peter, I am proposing something else for
timestamp proofs
Le 01/02/2023 à 01:46, Christopher Allen via bitcoin-dev a écrit :
> All other things being equal, which is better if you need to place a
> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
> spent taproot transaction such as:
>
> OP_FALSE
> OP_IF
> OP_PUSH my64bytes
> OP_ENDIF
>
> I know that the anti-OP_RETURN folk would say “neither.” But if there
> was no other choice for a particular protocol, such as a timestamp or
> a commitment, which is better? Or is there a safer place to put 64
> bytes that is more uncensorable but also does not clog UTXO space,
> only spent transaction `-txindex` space?
>
> My best guess was that the taproot method is better, but I suspect
> there might be some who disagree. I'd love to hear all sides.
>
> -- Christopher Allen
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230201/0fed77e3/attachment-0001.html>

2023-06-07 23:18:56 UTC

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: No one has answered the question of what is considered good practice for storing in Bitcoin, specifically regarding OP_RETURN rules, max size, and number of OP_RETURN per transaction.
📝 Original message:As far as I can read nobody replied to the initial question: what is
considered as good/best practice to store in Bitcoin?
Reiterating my question: what are the current rules for OP_RETURN, max
size and number of OP_RETURN per tx
Le 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit :
> On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:
>> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
>>>
>>> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> All other things being equal, which is better if you need to place a
>>>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>>>> taproot transaction such as:
>>>>
>>>> OP_FALSE
>>>> OP_IF
>>>> OP_PUSH my64bytes
>>>> OP_ENDIF
>>> What's wrong with OpPush <data> OpDrop?
>>>
>> This is a technical nit, but the reason is that <data> is limited to 520
>> bytes (and I believe, 80 bytes by standardness in Taproot), so if you
>> are pushing a ton of data and need multiple pushes, it's more efficient
>> to use FALSE IF ... ENDIF since you avoid the repeated DROPs.
> Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's
> not executed. But in this example we're just talking about 64 bytes, so that
> limit isn't relevant and OpPush <data> OpDrop should be sufficient.
>
> Specifically for more than 520 bytes you run into the the
> MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all
> scripts regardless of standardness at script execution:
>
> //
> // Read instruction
> //
> if (!script.GetOp(pc, opcode, vchPushValue))
> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
> return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/13100de1/attachment.html>

2023-06-07 18:29:30 UTC

- reply

📅 Original date posted:2021-03-14
📝 Original message:It's incredible how this troll keeps trolling and the list (bitcoin-dev
!!) keeping attention
Good troll, really
Le 14/03/2021 à 11:13, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a
écrit :
> Good Afternoon,
>
> Since this is on the list I will open without my thank-you. You will
> kindly be advised that my title are recorded in both Scotland and with
> England, also provided by record in Australia's account with names
> recorded. If you wonder than am I Wills it is because a long time
> before we ever saw Wills in print with an article provided reference to
> any Prince in the past thirty-years there I am Wills already. Title The
> Australian was prepared a long time to my requiest to wait until it was
> better presented, with at least some acquired experience in business to
> understand a market like BHP services. Thereby you accept a separate
> title Lord being with feudal and Lord being with the appointments
> direct to the service of the monarch's house Earl and similar up to
> Duke and King and higher being heard usually the monarch's preference
> Your Excellency or Your Highness being His service. I have never been
> any Prince. If any Prince titles came the instructions were they were
> retained to be considered not accepted not refused.
>
> If you had each fools to inquire.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this
> email if misdelivered.
> ------------------------------------------------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 13 March 2021 9:30 AM
> *To:* R E Broadley <rebroad+linuxfoundation.org at gmail.com>; Bitcoin
> Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Taproot NACK
>
> I’m pretty sure it’s subtle mockery. Even a legit title doesn’t
> warrant additional attention.
>
> e
>
> > On Mar 12, 2021, at 14:02, R E Broadley via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Can I just point out (to those addressing James as Lord/Excelency/etc
> > that he isn't noble nor a Lord, so just wanted to mention this in case
> > people were giving him more attention than the average person would be
> > afforded.
> >
> > My 2p (an equal 2p) on Taproot is ACK, by the way.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210314/e2f3f7d7/attachment.html>

2023-06-07 18:25:12 UTC

- reply

📅 Original date posted:2020-06-05
📝 Original message:Hi,
As far as I understand your answer is "let's try to use what exists",
this is not what I am proposing and not the Tor network, no "standard"
exit nodes, different hidden services, decentralized anonymizer network
unlike the Tor network, nodes are anonymizing themselves
Comments below, please let me know what is unclear in the description of
the project so I can modify it because all the time I get the impression
that it is mixed with the Tor network while it just has a very little to
do with it, and I don't get that the simple principle of communicating
between nodes using the Tor protocol without RDV points is never considered
Regards,
Le 05/06/2020 à 13:44, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> The issue each time there are discussions/research linking to Tor is that it is biased since the beginning because based on a wrong postulate: using the Tor network
>>
> Well, in the interest of using the wrong tool for a highly important job, let me present this thought:
Then for an important job people should use the right tool...
>
> * The Tor network is weakened due to its dependence on a limited set of exit nodes.
And centralized structure, limited set of nodes to make it short, for
some (or a lot) misbehaving, not designed for bitcoin, nothing prevents
bitcoin from operating its own anonymizer system, which I am proposing
> * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
Good to a certain extent... if you want to hide that you are operating a
bitcoin node you can use RDV points (ie hidden services) but if you
don't care you just connect anonymized circuits between bitcoin nodes,
this is more "direct" and does not exist in the Tor network, this
includes light clients that can act as relays also
> * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections.
There are plenty of Tor-to-Tor issues, not theoretical but in the real
world, "Tor-to-clearnet" can be done outside of the Tor network, ie the
bitcoin network
> * Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet.
Probably, again I am not proposing a remake of the Tor network, I don't
see the use for a miner to hide (neither for a bitcoin node to use RDV
points), but they can be part of the global anonymized system, please
see below
> * So make your own bridge between Tor and clearnet.
> * Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning).
> * One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP).
> * The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at.
> * Use the Tor-fullnode to propagate your transactions.
Yes but one full node should be able to do this alone, ie implement both
interfaces, like miners and everybody in fact (or Peersm bridges with
bittorrent if you look at the history of the project)
>
> Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.
> And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there.
Please see the convergence link, it's not based on the assumption that
"the more you are the better you can hide and the lesser you can get
attacked", this does not work at all, it's based on the assumption that
even with a reduced set of peers it becomes very difficult to know who
is doing what and whom is talking to whom, the concept of
exiting/bridging to clearnet(s) is not clearly detailed in this version
but appears on the drawings

2023-06-07 18:25:11 UTC

- reply

📅 Original date posted:2020-06-05
📝 Original message:Le 04/06/2020 à 04:58, ZmnSCPxj via bitcoin-dev a écrit :
>> [Tor is tricky](https://arxiv.org/abs/1410.6079) too
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes me that a mitigation would be to run your Bitcoin fullnode on clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) "only" loses you the ability to pay, receive, or route (and thereby earn forwarding fees), but as long as your blockchain view is clear, it should be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin node when transactions are broadcast with the attached Bitcoin node (as noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a different view-fullnode from the broadcast-fullnode.
>
The issue each time there are discussions/research linking to Tor is
that it is biased since the beginning because based on a wrong
postulate: using the Tor network
I will not elaborate on this again, it's an obvious very bad idea to use
the Tor network for bitcoin
It's not a bad idea to use the Tor protocol with no story of exit nodes
and hidden services, linking again to:
https://github.com/Ayms/node-Tor#phase-4-and-phase-5
And new link: http://www.peersm.com/Convergence-2020.pdf "A universal
and generic architecture to anonymize any application or protocol and
turn it into an independent decentralized p2p network inside browsers
and servers, with browsers acting as servers"
LN and bitcoin nodes would be relays and/or RDV points and/or clients
and serving parties, some Tor network nodes could be used in the middle
also (relays only) but in any case sybils/eclipse attacks become much
more difficult to perform (or unlikely depending on how the peer
discovery system is designed)
bitcoin | node-Tor |bitcoin and LN.pipe(node-Tor)
Then question for possible future tests: is there a simple way to pipe
the bitcoin protocol via stdin/stdout? (the socks interface could be
used but we already saw that it did raise issues)
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200605/c512ceb6/attachment.html>

2023-06-07 18:21:40 UTC

- reply

📅 Original date posted:2019-11-08
📝 Original message:Sure, but what is questionable here is the use of SOCKS proxy, for Tor I
think as the main purpose, making it dangerous for the "whole bitcoin
world" while it's something like of zero interest/use (or please let me
know what it is beside Tor)
The Tor network is very centralized and not designed at all to handle
p2p networks (which bitcoin is still not), it is designed to be used via
the Tor Browser to browse the web and to hide web servers, not bitcoin
nodes, and there are a lot of misbehaving/dangerous nodes there, there
is no encryption in bitcoin protocol, an exit node can fake whatever it
likes, this seems to be a use case as far as I can see, but even if the
initiator is configured to connect to a hidden bitcoin node, I don't see
the point
I have advertised recentlty the open sourcing of node-Tor
(https://github.com/Ayms/node-Tor) here
This one is designed for p2p, not over the Tor network but using the Tor
protocol, as simple as bitcoin.pipe(node-Tor), or <any
protocol>.pipe(node-Tor), which is the finality of the project as far as
I see it since years (maybe see http://www.peersm.com/Convergence.pdf
even if I would modify some parts now)
Inside servers or browsers acting as servers also (WebRTC or
WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin
anonymized protocol using the Tor protocol (and not the Tor network)
between each others, there is no story of exit nodes here and rdv points
would not apply for bitcoin use, this "just" adds the internal missing
encryption and anonymity layer to the bitcoin protocol
Personally I would remove the socks proxy interface from bitcoin core,
independently of Tor this can be misused too and offers absolutely zero
security
Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a
écrit :
> It goes without saying in that all privately known CVE should be
> handled so professionally but, that is, well done team.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> ------------------------------------------------------------------------
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org
> <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Luke
> Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 9 November 2019 2:07 AM
> *To:* bitcoin-dev at lists.linuxfoundation.org
> <bitcoin-dev at lists.linuxfoundation.org>
> *Cc:* security at bitcoincore.org <security at bitcoincore.org>
> *Subject:* [bitcoin-dev] CVE-2017-18350 disclosure
>
> CVE-2017-18350 is a buffer overflow vulnerability which allows a
> malicious
> SOCKS proxy server to overwrite the program stack on systems with a
> signed
> `char` type (including common 32-bit and 64-bit x86 PCs).
>
> The vulnerability was introduced in
> 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
> (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012
> Aug 27.
> A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 ("Improve
> and
> document SOCKS code") released in v0.15.1, 2017 Nov 6.
>
> To be vulnerable, the node must be configured to use such a malicious
> proxy in
> the first place. Note that using *any* proxy over an insecure network
> (such
> as the Internet) is potentially a vulnerability since the connection
> could be
> intercepted for such a purpose.
>
> Upon a connection request from the node, the malicious proxy would
> respond
> with an acknowledgement of a different target domain name than the one
> requested. Normally this acknowledgement is entirely ignored, but if the
> length uses the high bit (ie, a length 128-255 inclusive), it will be
> interpreted by vulnerable versions as a negative number instead. When the
> negative number is passed to the recv() system call to read the domain
> name,
> it is converted back to an unsigned/positive number, but at a much
> wider size
> (typically 32-bit), resulting in an effectively infinite read into and
> beyond
> the 256-byte dummy stack buffer.
>
> To fix this vulnerability, the dummy buffer was changed to an explicitly
> unsigned data type, avoiding the conversion to/from a negative number.
>
> Credit goes to practicalswift (https://twitter.com/practicalswift) for
> discovering and providing the initial fix for the vulnerability, and
> Wladimir
> J. van der Laan for a disguised version of the fix as well as general
> cleanup
> to the at-risk code.
>
> Timeline:
> - 2012-04-01: Vulnerability introduced in PR #1141.
> - 2012-05-08: Vulnerability merged to master git repository.
> - 2012-08-27: Vulnerability published in v0.7.0rc1.
> - 2012-09-17: Vulnerability released in v0.7.0.
> ...
> - 2017-09-21: practicalswift discloses vulnerability to security team.
> - 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
> - 2017-09-27: Fix merged to master git repository.
> - 2017-10-18: Fix merged to 0.15 git repository.
> - 2017-11-04: Fix published in v0.15.1rc1.
> - 2017-11-09: Fix released in v0.15.1.
> ...
> - 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
> - 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/e9797500/attachment.html>

2023-06-07 18:18:24 UTC

- reply

📅 Original date posted:2019-05-26
📝 Original message:I did not phrase correctly in fact, what I meant is: if the validator
sees empty or witness script in scriptSig, then this is a segwit input,
and doing this one by one the validator can associate the correct segwit
data to the correct segwit input, so 00 does not look to be needed
Le 26/05/2019 à 18:28, Johnson Lau a écrit :
> This is not how it works. While the transaction creator may know which inputs are segwit, the validators have no way to tell until they look up the UTXO set.
>
> In a transaction, all information about an input the validators have is the 36-byte outpoint (txid + index). Just by looking at the outpoint, there is no way to tell whether it is segwit-enabled or not. So there needs to be a way to tell the validator that “the witness for this input is empty”, and it is the “00”.
>
>> On 27 May 2019, at 12:18 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>>
>> ……. for the 00 number of witness
>> data for non segwit inputs the one that is doing the transaction knows
>> which inputs are segwit or not, then parsing the transaction you can
>> associate the correct input to the correct witness data, without the
>> need of 00, so I must be missing the use case
>

2023-06-07 18:18:23 UTC

- reply

📅 Original date posted:2019-05-26
📝 Original message:OK, thanks, understood for OP_0 but still for the 00 number of witness
data for non segwit inputs the one that is doing the transaction knows
which inputs are segwit or not, then parsing the transaction you can
associate the correct input to the correct witness data, without the
need of 00, so I must be missing the use case
Le 26/05/2019 à 16:33, Johnson Lau a écrit :
>> On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I realized recently that my segwit implementation was not correct,
>> basically some time ago, wrongly reading the specs (and misleaded by
>> what follows), I thought that scriptsig would go into witness data as it
>> was, but that's not the case, op_pushdata is replaced by varlen
>>
> Witness is not script. There is no op_pushdata or any other opcodes.
>
> Witness is a stack. For each input, the witness starts with a CCompactSize for the number of stack elements for this input. Each stack element in turns starts with a CCompactSize for the size of this element, followed by the actual data
>
>
>> Now reading correctly the specs, they seem to be not totally correct,
>> then the first question is: why OP_0 is 00 in witness data and not 0100?
>> Does this apply to other op_codes? This does not look logical at all
>>
> A “00” element means the size of this element is zero. Since it’s zero size, no data is followed. This will create an empty element on the stack. It’s effectively same as OP_0 (Again, witness is not script)
>
> A “0100” element means the element size is one, and the data for this element is “00”. So it will leave an 1-byte element on the stack.
>
>
>> The second question is: why for non segwit inputs there is a 00 length
>> in segwit data, what is the rational for that? It should just be nothing
>> since you don't need this to reconciliate things
> The “00” here means "this input has no witness stack element”. You need this even for non segwit inputs, because there is no way to tell whether an input is segwit-enabled or not, until you look up the UTXO, which might not be always available. Transaction serialization couldn’t rely on contextual information.
>
> However, if all inputs have no stack element, the spec requires you to always use the non-segwit serialization.
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:18:22 UTC

- reply

📅 Original date posted:2019-05-25
📝 Original message:I realized recently that my segwit implementation was not correct,
basically some time ago, wrongly reading the specs (and misleaded by
what follows), I thought that scriptsig would go into witness data as it
was, but that's not the case, op_pushdata is replaced by varlen
Now reading correctly the specs, they seem to be not totally correct,
then the first question is: why OP_0 is 00 in witness data and not 0100?
Does this apply to other op_codes? This does not look logical at all
The second question is: why for non segwit inputs there is a 00 length
in segwit data, what is the rational for that? It should just be nothing
since you don't need this to reconciliate things

2023-06-07 18:17:54 UTC

- reply

📅 Original date posted:2019-05-03
📝 Original message:Great doc, thanks, then my previous summarized conclusion was wrong,
trying on my side to write a "demistifying (simply) once for all bitcoin
scripting", not sure that "simply" can stay in the title at the end...
So my multisig modification is non standard, now I am still puzzled by
something, mainly the fact that we have op_pushdata inside op_pushdata,
maybe I am misreading the specs, but in case of p2sh only the last
op_pushdata (called {serialized script} (or redeem script) is executed,
then if succesfull it comes back onto the stack and scriptpubkey is executed
So, let's take again the BCH recovery example, scriptSig was OP_PUSHDATA
0014<hash160 of pubkey>, and scriptPubKey OP_HASH160 <hash160 of
0014<hash160 of pubkey> OP_EQUAL, then scriptSig executes pushing
nothing and <hash160 of pubkey> into the stack, then scriptSig is pushed
again and executed with scriptPubKey, at the end we get nothing +
<hash160 of pubkey> + 1 in the stack, then cleanstack (maybe among
others, I have to read in more details your doc) says it is a correct
transaction but non standard, is this correct?
Le 03/05/2019 à 01:33, James Prestwich a écrit :
> Hi Aymeric,
>
> As Luke and ZmnSCPxj have pointed out, documenting standardness is
> sisyphean, as it varies from version to version. I recently put
> together a reference for default TX_NONSTANDARD policies in v0.18,
> which can be found here: https://prestwi.ch/the-bitcoin-nonstandard/
>
> It applies only to v0.18, and may already be outdated.
>
> Best,
> James
>
> On Thu, May 2, 2019 at 4:29 PM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Thanks for the answer, indeed for the redeem script and someone
> attempting a 0/1 of 3, good example
>
> So to summarize everything is standard as long as it matches P2PKH,
> P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in
> op_return
>
> Still the case of bch is unclear (it's related since based on bitcoin
> code unless they changed the policy), was the story that nodes
> would not
> propagate the fix or that people did not want to take the risk to
> propagate it? And why a non segwit old bitcoin node would not
> accept it
> either?
>
> Le 02/05/2019 à 02:10, ZmnSCPxj a écrit :
> > Good morning Aymeric,
> >
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte
> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
> >
> >> I must badly explain my point (or just wondering things that do not
> >> exist finally), the question is indeed whether nodes will relay non
> >> usual transactions or not and how to know what they will accept
> or not:
> >>
> >> - my modified multisig 2 of 3: I did put OP_2 out of the
> usual redeem
> >> script, the redeem script still matches scriptpubkey and
> scriptsig will
> >> execute succesfully, that's a normal legacy P2SH or segwit
> P2WSH
> >>
> >> - bch segwit recovery: it's a p2sh transaction without any
> signature
> >> verification, as far as I remember there was a story that
> it could not
> >> propagate in the network (even taking the risk to be
> stolen) and that
> >> people had to contact a (honest) miner
> >>
> >> - sha bounties: same as above, p2sh transactions without
> signatures
> >>
> >> etc
> >>
> >> Will all of those transactions propagate normally? And then
> the rule is
> >> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH
> templates
> >> whatever scripts you put inside?
> > P2PKH and P2WPKH cannot have custom script.
> > However, yes, any custom script can be wrapped in P2SH and P2WSH
> and it will be propagated.
> > The P2SH/P2WSH hides the details of your custom script so cannot
> be filtered based on your custom script.
> > Do realize that once a claim on your modified x-of-3 is
> propagated your `redeemScript` is known and someone can attempt to
> RBF (or coordinate with a miner) with a modified `witness` stack
> or `scriptSig` to claim your UTXO.
> > (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at
> least one of your signatories could make it a 1-of-3 and bribe a
> miner to get it claimed)
> >
> > I cannot answer for BCH; arguably that is off-topic here.
> >
> > The old SHA bounty transactions were propagated in the days
> before `isStandard` I think.
> > Either that or they were put in by miners.
> > An SHA bounty can still be propagated today if they are wrapped
> in a P2SH or P2WSH, but you have to publish the `redeemScript`
> yourself in some other method.
> > Or bribe a miner if the transaction is not time-sensitive (for
> an SHA bounty, unlikely to be time-sensitive).
> >
> > Regards,
> > ZmnSCPxj
>
> --
> Move your coins by yourself (browser version):
> https://peersm.com/wallet
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor <https://github.com/Ayms/torrent-livenode-Tor> :
> https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190503/fa40d55f/attachment-0001.html>

2023-06-07 18:17:50 UTC

- reply

📅 Original date posted:2019-04-27
📝 Original message:Maybe trivial question but asking here because I can't find anything
clear (or updated) about it: is somewhere explained in details what txs
are considered standard and non standard today without having to read
the core code?
For example, modification of multisig 2 of 3:
scriptSig:
    OP_0
    OP_PUSHDATA sign1
    OP_PUSHDATA sign2
    OP_2
    OP_PUSHDATA <pubkey1><pubkey2><pubkey3> OP_3 OP_CHECKMULTISIG
scriptPubKey:
    OP_HASH160 hash160(<pubkey1><pubkey2><pubkey3> OP_3
OP_CHECKMULTISIG) OP_EQUAL
Is this standard? Are lightning txs standards ? etc

2023-06-07 18:16:38 UTC

- reply

📅 Original date posted:2019-03-14
📝 Original message:Apparently I don't have the same experience than others here, what I
encountered is no reject message received for wrong txs, but from what I
understand here it's not unusual to receive reject message for valid
txs, then I don't see how it can be really helpful/relied, given also
that the reject messages are unclear and even can be misleading
As it was written already I found it useful only for debugging purposes,
at least it can give some kind of ideas about what happened,
bitcoin-transactions is implementing the bitcoin protocol but does not
act as a node and does not pretend to fake a node behavior waiting for
example to get the tx back, is the method of sending a getdata for a
given tx to see if it was accepted by a node wrong ? It can't guarantee
100% that it was successful and will propagate but I see that you are
doing completely different things
Le 13/03/2019 à 23:30, Dustin Dettmer via bitcoin-dev a écrit :
> I’ve solved the same problem in a different way.
>
> 1) Submit a transaction
> 2) Collect all reject messages (that have matching txid in the reject
> data)
> 3) Wait 16 seconds after first error message received (chosen
> semirandomly from trial and error) before processing errors
> 4) Wait for our txid to be submitted back to us through the mempool,
> if we get it notify success and delete all pending error events
> 5) Signal failure with the given reject code if present (after the 16
> seconds have elapsed)
> 6) If no error or success after 20 seconds, signal timeout failure
>
> This works fairly well in testing. Newer transaction types seem to
> generate reject codes 100% of the time (from at least one node when
> sending to 4 nodes) so this culling / time delay approach is
> essentially required.
>
> On a related note: One issue is that RBF attempts with too small a fee
> and accidental double spends (with enough fee for 1 tx but not a RBF)
> both generate the same reject code: not enough fee.
>
> A new reject code for RBF based too small of fee would definitely make
> for a better user experience as I’ve seen this exact problem create
> confusion for users.
>
> Removing reject codes would make for a much worse user experience.
> “Your tx failed and we have no idea why” would be the only message and
> it would require waiting for a full timeout.
>
> On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190314/49975469/attachment-0001.html>

2023-06-07 18:16:38 UTC

- reply

📅 Original date posted:2019-03-07
📝 Original message:Bitcoin-transactions did use this "feature", but does not rely on it any
longer since I observed some strange behavior sometimes (no reject
message for bad tx, with suprnova for example as far as I remember),
then it doublechecks using getdata to see if the tx is in mempool
Indeed you can't trust what a node tells you with or without reject
(idem for getdata but more difficult to fake and better than nothing)
Then I don't see any problem to remove it, taking into account also that
the error message is too vague to be really helpful
https://github.com/bitcoin/bitcoin/issues/11891
Le 06/03/2019 à 01:53, Marco Falke via bitcoin-dev a écrit :
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected to a
> trusted node. At this time, I am not aware of any software that requires this
> feature, and I would like to remove if from Bitcoin Core to make the codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network protocol
> should be done by inspecting the log messages that are produced by a recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee estimation
> to determine transaction fees and set replace-by-fee if desired. Thus, they
> could wait until the transaction has confirmed (taking into account the fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:16:30 UTC

- reply

📅 Original date posted:2019-02-18
📝 Original message:Then, since you wrote this proposal, maybe you should add the very
precise description of the signing/verification process since it is
documented nowhere
I don't get the use of the speech regarding keys while it should focus
on signatures which are summarized in a vague sentence inspired by your
ref [2] with a not very logical link to the next paragraph stating that
r,s should be 32B and the whole thing 65B with a header of 1B, you did
not invent it, that's probably the rule, not sure where it is specified
again and for what purpose, the header seems completely of no use
especially when you extend to segwit/bech32 since you just have to check
that related compressed key matches
Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
> I have written up a proposed BIP. It has to do with Signature formats
> when using Bitcoin Private keys. It is
> here: https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github
> issue: https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps
> are with regards to getting a BIP number assigned or any other process
> steps required.
>
> Regards,
> Chris
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190218/971a925a/attachment-0001.html>

2023-06-07 18:15:55 UTC

- reply

📅 Original date posted:2019-01-01
📝 Original message:You are simplifying too much what I am suggesting
What I am suggesting is: set a derivation method for BIP39 like for
BIP32 (having the seed for BIP32 and not the derivation path is just
like having nothing) and use this derivation method from a "book" (a
"book" being a book, a document, a link, an image, whatever your secret
can be), based on the fact that you will easily find from this
derivation method "valid" BIP39 seeds (even if BIP39 does not enforce
anything regarding valid phrases, everything can be valid as you
mention, and this does not help in fact)
The derivation method will just define the way you select the words in
the secret, and if everybody chooses the bible as the secret then this
will not change the fact that it will be impossible to find the real
seed without knowing the derivation path
Then you don't need to write the seed, you can easily plausible deny it,
you can easily pass it to the family (using a passphrase does not say to
them where they are supposed to use it)
"people lost"--> people think that there is some magic with BIP39 that
will save them whatever they do (ie they don't even care of managing
correctly the many easy to generate BIP39 seeds they are using) where
they will always recover their seed and keys from BIP39/44/49, of course
this does not work at all
Le 31/12/2018 à 17:52, Alan Evans a écrit :
> > Using some algorithm to take some input and generate a bip39 phrase
> that you can use with any bip39 wallet sounds perfectly reasonable.
>
> I think any method that doesn't use real entropy, but some fake source
> of randomness, such as a book is asking to be hacked and so is not a
> reasonable idea.
>
> If an algorithm for book text to BIP39 sentence ever became well used,
> common books will be systematically searched for accounts. People will
> also choose their favourite passages, so I would expect to see collisions.
>
> You should also note that BIP39 does not need input that is from the
> word list. You can use _any text as its input_, the word list and
> checksum check is just recommended to be a warning, but again, text
> chosen from public sources or common phrases is a bad idea for many
> reasons.
>
> From BIP0039:
> /> The conversion of the mnemonic sentence to a binary seed is
> completely independent from generating the sentence. This results in
> rather simple code; *there are no constraints on sentence structure*
> and clients are free to implement their own wordlists or even whole
> sentence generators, allowing for flexibility in wordlists for typo
> detection or other purposes./
> /> Although using a mnemonic not generated by the algorithm described
> in "Generating the mnemonic" section is possible, this is not advised
> and software must compute a checksum for the mnemonic sentence using a
> wordlist and issue a warning if it is invalid./
>
> What you could do is use a regular true random BIP39 sentence in
> conjunction with a phrase from a book as the "passphrase" giving you
> that plausible deniability, right up to the point you put that in your
> will or tell someone, i.e. for the "what if something happens to me"
> case. Though I still think redirecting people to a book phase is risky
> for this, e.g. books have editions, there may be a change in the key
> place.
>
> From BIP0039:/
> /
> /> The described method also provides plausible deniability, because
> every passphrase generates a valid seed (and thus a deterministic
> wallet) but only the correct one will make the desired wallet available./
>
> Alan
>
> P.S. "I have seen many people completely lost with their wallets
> because of [BIP39]": I would say "despite" not "because". These people
> would have lost/miss recorded a BIP32 hex seed as well.
>
>
> On Thu, 27 Dec 2018 at 11:02, Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> Le 26/12/2018 à 19:54, James MacWhyte a écrit :
>>
>> On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte
>> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
>>
>> so, even with a tool like yours, they can be misleaded, for
>> example trying a few words to replace the missing/incorrect
>> one, get a valid seed and stay stuck with it forever trying
>> to play with BIP44/49 to find their keys
>>
>>
>> Just a small detail, but my tool actually looks up all the
>> possible combinations and then finds which one has been used
>> before by looking for past transactions on the blockchain.
>> Therefore, it won't tell you your phrase is correct unless it is
>> a phrase that has actually been used before (preventing what you
>> described).
>
> I saw that your tool was querying blockchain.info
> <http://blockchain.info>, but it cannot guess what derivation path
> was used and if it is a standard one what addresses were used, and
> even if successful it works only for bitcoin (so maybe it should
> just output the ~1500 possible phrases and/or xprv, and be
> completely offline, this is still doable for people)
>
>>
>> Using some algorithm to take some input and generate a bip39
>> phrase that you can use with any bip39 wallet sounds perfectly
>> reasonable.
>
> I forgot to mention that this can help also solving the "what if
> something happens to me" case giving to the family the seed and
> the parameter(s) for the derivation path, or an easy way to find
> it (better than something like: remind this passphrase, take the
> sha256 of it, then use some other stuff to find the encryption
> algo, take n bytes of the hash, use it to decode my wallet or my
> seed... and then everybody looking at you like crazy)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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/20190101/916f37ee/attachment-0001.html>

2023-06-07 18:15:52 UTC

- reply

📅 Original date posted:2018-12-26
📝 Original message:Another drawback I think is that people are not using it as seeds, they
just go to a wallet sw which proposes a new seed, write it somewhere, do
something with the wallet and forget about it, go to another one, create
another wallet, etc
Apparently it is not very well known even here that the probabilities
are very high to get a valid BIP39 seed even with 24 words, so, even
with a tool like yours, they can be misleaded, for example trying a few
words to replace the missing/incorrect one, get a valid seed and stay
stuck with it forever trying to play with BIP44/49 to find their keys
Probably what I am suggesting is not new (and therefore maybe not a good
suggestion): given a secret seed (a book, a document, a link, etc) and a
derivation path (an algo with secret parameter(s) to derive/order the
words and select the valid bip39 sequences), you get your BIP39 seeds
and don't have to write them
Of course we don't have to use necessarilly BIP39 for this but this is
what we have everywhere and this is what is compatible with it, then you
could use the same or a fake written "not very well hidden" BIP39 seed
to plausibly deny your real wallet
Le 25/12/2018 à 01:30, James MacWhyte a écrit :
>
>
> On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> I don't see very well why it's easier to write n words that you
> cannot choose rather than a 32B BIP32 hex seed, and I have seen
> many people completely lost with their wallets because of this
>
>
> In practice it has quite a few qualities that make it a bit more
> resilient for physical (written) storage.
>
> If a few letters of a word get rubbed off or otherwise become
> illegible, it is pretty easy for a native speaker to figure out what
> the word is supposed to be. Even a non-native speaker could look
> through the word list and figure out which word fits. Missing
> characters in a hex string require more advanced brute force
> searching, which the average user isn't capable of.
>
> Additionally, having the bits grouped into words makes a more serious
> recovery easier. If you lose one entire word, it can be brute forced
> in about 5 minutes on a normal pc, even if you don't know which
> position the missing word is in (I have published a tool that does
> just this: https://jmacwhyte.github.io/recovery-phrase-recovery). If
> you are missing two words, you can brute force it in about a week
> (napkin math).
>
> If you were missing a random chunk of a hex string, I don't know how
> you'd go about brute forcing that in a timely manner.
>
> As an aside, from a UX standpoint we've seen that the 12 words don't
> *look* important so people don't take them seriously (and they get
> lost). A hex string or equivalent would look more password-y, and
> therefore would most likely be better protected by users.
>
> James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181226/e047093a/attachment-0001.html>

2023-06-07 18:15:51 UTC

- reply

📅 Original date posted:2018-12-23
📝 Original message:Exactly
This is surprising, I would have expected the probabilities to be much
more lower
It just means that scanning whatever (secret) book, document, link, etc,
you will find easily BIP39 seeds, even of 24 words
So, it just means that you don't have to write your seed since you can
recover it that way, given a secret source and specific algo with custom
parameters, this could be used for plausible deniability also
For now I still dislike BIP39 and alike (because I don't see very well
why it's easier to write n words that you cannot choose rather than a
32B BIP32 hex seed, and I have seen many people completely lost with
their wallets because of this), but I could change my mind, and despite
of further improvements for this ratio, could what I am suggesting make
sense?
Le 23/12/2018 à 19:46, Pavol Rusnak a écrit :
> On 22/12/2018 00:58, Aymeric Vitte via bitcoin-dev wrote:
>> Has anybody already looked at this: given N randomly chosen words
>> belonging to a BIP39 2048 words dictionary, what is the probability to
>> get a "valid" BIP39 seed (ie with the right checksum)?
> 1:256 for 24 words
> 1:16 for 12 words
>
> This ratio is not too great and will be improved in the upcoming SLIP39
> standard: https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>

2023-06-07 18:15:51 UTC

- reply

📅 Original date posted:2018-12-21
📝 Original message:Has anybody already looked at this: given N randomly chosen words
belonging to a BIP39 2048 words dictionary, what is the probability to
get a "valid" BIP39 seed (ie with the right checksum)?
The result looks (very) surprising to me and might have some use cases,
just would like to know if this topic has already been discussed before
going further
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:10:47 UTC

- reply

📅 Original date posted:2018-02-13
📝 Original message:No, the problem is not bitcoin being under any kind of attack by the
forks for me, but the forks fooling people because, again, reusing the
bitcoin core code is too easy
I don't know if there can be a legal solution to this which would keep
some open source aspect of the code, but at least it deserves to be studied
Le 13/02/2018 à 16:24, Jameson Lopp via bitcoin-dev a écrit :
> If I'm understanding the problem being stated correctly:
>
> "Bitcoin is under a branding attack by fork coins."
>
> The proposed solution is to disincentivize fork coins from using the
> word Bitcoin by altering the license terms. I'm not a lawyer, but it
> seems to me that the words of the license are basically useless unless
> there is an entity that intends to make use of court systems to
> threaten noncompliant projects into submission.
>
> In my opinion, the perceived attack on Bitcoin here is social /
> marketing-based, thus it makes sense that any defense against said
> attack should also be social / marketing-based. I don't think that
> Bitcoin should be reliant upon courts or governments to defend itself
> against attacks of any form.
>
> On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
>
> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via
> bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>>:
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT
> THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS
> MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT
> PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN
> ***
>
>
> That's better solved with trademarks. (whoever would be the
> trademark holder - Satoshi?)
>
> This would also prohibit any reimplementation that's not formally
> verified to be perfectly compatible from using the name.
>
> It also adds legal uncertainty.
>
> Another major problem is that it neither affects anybody forking
> older versions of Bitcoin, not people using existing independent
> blockchain implementations and renaming them Bitcoin-Whatsoever.
>
> And what happens when an old version is technically incompatible
> with a future version by the Core team due to not understanding
> various new softforks? Which version wins the right to the name?
>
> Also, being unable to even mention Bitcoin is overkill.
>
> The software license also don't affect the blockchain data.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180213/3121c4e7/attachment-0001.html>

2023-06-07 18:00:23 UTC

- reply

📅 Original date posted:2017-04-20
📝 Original message:Thanks but you did not answer all the points and some of your statements
look wrong, like the global ideas behind this proposal from my
standpoint, which basically is inventing strange things not reusing what
is already proven to be working well and could provide the same result,
which at the end is not the expected one, ie increasing full nodes, it
sounds like a strange workaround to prevent the centralization of the
blockchain when pruning will become the default
To answer some other comments in this thread, giving an incentive to run
full nodes does not mean that someone setting up tomorrow 10K nodes will
become rich and/or will be able to control the network, the later being
not unlikely at all to happen in the current situation, the idea is more
to motivate people that already have the resources to run full nodes,
then we mix the concepts of optimizing the resources at no additional
costs (and even decreasing costs since you get rewarded for the part
that you have already paid but don't use) with the one of running nodes
to protect its business
For example
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf#proposal
is showing some concepts where nodes can't position themselves where
they like and are registered in the system by the others (but forget the
proof of something as written in this gist since I think the rewards
should not depend on usual miners) , so it becomes quite difficult that
they position themselves where they like to possibly get the rewards,
fake the system, freeride, cheat, collude in pools or setup plenty of nodes
Comments below
Le 19/04/2017 à 19:30, David Vorick via bitcoin-dev a écrit :
> On Tue, Apr 18, 2017 at 3:43 AM, Jonas Schnelli <dev at jonasschnelli.ch
> <mailto:dev at jonasschnelli.ch>> wrote:
>
> I know many torrent clients, and clients for protocols like Tor
> and i2p include the ability to set both speed limits and monthly
> bandwidth limits.
>
Yes, that's the easy part, the issue is more for the network to check
that users have sufficient bandwidth and don't cheat
> I worry about any type of CDN being a central point of failure.
Of course
> Torrenting typically relies on a DHT, which is much easier to attack
> than Bitcoin's peer network.
Then please explain how you would attack the bittorrent DHT and why it's
"much easier" than attacking the btc network today, bittorrent is not
designed for security/privacy, including its DHT, which btw is great,
it's a common sign of misinformation to conclude that all DHTs are
necessarily insecure
> I think the bitcoin p2p network is by significant margin the best
> we've got.
The btc network can't be considered as a p2p network in its current form
then can't be the best one for now (and if it was then we would not be
in today's situation)
>
> Yes, there is finger-print that happens if you have nodes pick an
> index. And the fingerprint gets a lot worse if you have a node pick
> multiple indexes.
This is another problem of your proposal, as well as
fingerprinting/tracking peers based on what they have
> Though, isn't it already required that nodes have some sort of IP
> address or hidden service domain? I want to say that the fingerprint
> created by picking an index is not a big deal, because it can be
> separated from activity like transaction relaying and mining. Though,
> I am not certain and perhaps it is a problem.
Are you suggesting that the btc "p2p" network should be using the Tor
network, and especially the nodes hosting the/(a part of) the
blockchain? This is of course a very bad idea and you would not
eliminate the tracking issue, a simple example is that despite ot the
size of the network it's not difficult to track the peers on the
bittorrent network, you might not know who is the peer but you can
follow whatever he is doing, and hidding behind Tor or a VPN does not
prevent this
>
>
>
> On Mon, Apr 17, 2017 at 6:14 AM, Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> While I fully agree with the intent (increasing full nodes so a
> big miner waking up in a bad mood can't threaten the world any
> longer every day as it is now) I am not sure to get the interest
> of this proposal, because:
>
> - it's probably not a good idea to encourage the home users to run
> full nodes, there are many people running servers far from their
> capacity that could easily run efficient full nodes
>
> Running a full node is the only way to avoid needing to trust others.
> It's also how you make your opinion worthwhile for events like hard
> forks and UASFs. If decentralization is the primary motivation, it
> absolutely makes sense to encourage people to run their own full
> nodes. Without a full node, you are at the mercy of the governance
> decisions by those who do have full nodes. But if you have a full
> node, you can chose to opt-out of any upgrade (example: ethereum
> classic nodes).
If you really know the Tor network, then you know why encouraging home
users to run full nodes is probably not a good idea
"Probably" because the situation is not the same for btc and indeed UASF
for example is referring to "users" who today are not really "users" but
intermediate nodes, so the decision finally is not made by the users
>
>
> - if someone can't allocate 100 GB today to run a full node, then
> we can't expect him to allocate more in the future
>
> That's why I'm proposing something to decrease the storage requirements.
This is just delaying the problem, you are just proposing to store some
parts of the blockchain not explaining how the peers will first setup
the nodes, some parts that will of course increase... then falling back
in the issue that you are trying to address
>
>
> - this proposal is a kind of reinventing torrents, while limiting
> the number of connections to something not efficient at all, I
> don't see why something that is proven to be super efficient
> (torrents) would be needed to be reinvented, I am not saying that
> it should be used as the bittorrent network is doing but the
> concepts can be reused
>
> It's different from torrents in that it uses specialized erasure
> coding to make sure that every block is always available, even if an
> adversary is running around targeting all the nodes with a particular
> piece.
You are reinventing something that would be achieved easily using the
concepts of torrents or incremental ones (ie someone would seed the
whole thing, some others some parts of it, etc)
>
>
> - I don't get at all the concept of "archival" nodes since it's
> another useless step toward centralization
>
> "archival" nodes are simply nodes with the full blockchain. Nobody can
> bootstrap on the network without them. Today, every bitcoin-core node
> is an archival node by default.
What I meant is that you can't build a hierarchy of btc nodes: big
nodes, medium nodes, small nodes, each node is free to decide how/if it
participates to the network, so the wording of "archival" nodes for me
is not adapted since it makes immediately think to centralized entities,
big organizations hosting the blockchain, etc
> I think the only way to increase full nodes it to design an
> incentive for people to run them
>
> The primary incentive is the sovereignty that it gives you. Running a
> Bitcoin full node gives you security and protection against political
> garbage that you can't get any other way. The network does currently
> depend on altruism to allow people to download the blockchain, but as
> long as we can keep the resource requirements of this altruism low, I
> think we can expect it to continue. This proposal attempts to keep
> those requirements low.
This is the usual answer but I don't believe it, people will rely on
others to run full nodes and secure them, and so on...
>
>
>
> I believe that my proposal does meet all of the requirements listed by
> Maxwell.
I did noy read them again, some others are listed in the link above
> Having a set of 8 random peers gives you a very high probability of
> being able to recover every single block. You would need to connect to
> at least 5 peers (and this is already >90% likely to be sufficient to
> recover every block), but if you cannot connect to 5 random peers your
> node is probably in trouble anyway. Highly parallel, high speed
> downloads are just as possible with small nodes as with archive nodes.
> It only takes a few bytes to indicate which part of the blockchain you
> have, and any 2 peers have a less than 1% chance of overlapping.
Again, you don't explain how you bootstrap the full nodes first, which
is the main issue, and if the idea is that the pruning nodes will never
desync then you should try downloading x GB to resync connecting to 5/8
peers possibly operating from home in different countries
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170420/6fff421d/attachment-0001.html>

2023-06-07 18:00:20 UTC

- reply

📅 Original date posted:2017-04-17
📝 Original message:While I fully agree with the intent (increasing full nodes so a big
miner waking up in a bad mood can't threaten the world any longer every
day as it is now) I am not sure to get the interest of this proposal,
because:
- it's probably not a good idea to encourage the home users to run full
nodes, there are many people running servers far from their capacity
that could easily run efficient full nodes
- if someone can't allocate 100 GB today to run a full node, then we
can't expect him to allocate more in the future
- the download time is a real concern
- this proposal is a kind of reinventing torrents, while limiting the
number of connections to something not efficient at all, I don't see why
something that is proven to be super efficient (torrents) would be
needed to be reinvented, I am not saying that it should be used as the
bittorrent network is doing but the concepts can be reused
- I don't get at all the concept of "archival" nodes since it's another
useless step toward centralization
I think the only way to increase full nodes it to design an incentive
for people to run them
Le 17/04/2017 à 08:54, David Vorick via bitcoin-dev a écrit :
> *Rationale:*
>
> A node that stores the full blockchain (I will use the term archival
> node) requires over 100GB of disk space, which I believe is one of the
> most significant barriers to more people running full nodes. And I
> believe the ecosystem would benefit substantially if more users were
> running full nodes.
>
> The best alternative today to storing the full blockchain is to run a
> pruned node, which keeps only the UTXO set and throws away already
> verified blocks. The operator of the pruned node is able to enjoy the
> full security benefits of a full node, but is essentially leeching the
> network, as they performed a large download likely without
> contributing anything back.
>
> This puts more pressure on the archival nodes, as the archival nodes
> need to pick up the slack and help new nodes bootstrap to the network.
> As the pressure on archival nodes grows, fewer people will be able to
> actually run archival nodes, and the situation will degrade. The
> situation would likely become problematic quickly if bitcoin-core were
> to ship with the defaults set to a pruned node.
>
> Even further, the people most likely to care about saving 100GB of
> disk space are also the people least likely to care about some extra
> bandwidth usage. For datacenter nodes, and for nodes doing lots of
> bandwidth, the bandwidth is usually the biggest cost of running the
> node. For home users however, as long as they stay under their
> bandwidth cap, the bandwidth is actually free. Ideally, new nodes
> would be able to bootstrap from nodes that do not have to pay for
> their bandwidth, instead of needing to rely on a decreasing percentage
> of heavy-duty archival nodes.
>
> I have (perhaps incorrectly) identified disk space consumption as the
> most significant factor in your average user choosing to run a pruned
> node or a lite client instead of a full node. The average user is not
> typically too worried about bandwidth, and is also not typically too
> worried about initial blockchain download time. But the 100GB hit to
> your disk space can be a huge psychological factor, especially if your
> hard drive only has 500GB available in the first place, and 250+ GB is
> already consumed by other files you have.
>
> I believe that improving the disk usage situation would greatly
> benefit decentralization, especially if it could be done without
> putting pressure on archival nodes.
>
> *Small Nodes Proposal:*
>
> I propose an alternative to the pruned node that does not put undue
> pressure on archival nodes, and would be acceptable and non-risky to
> ship as a default in bitcoin-core. For lack of a better name, I'll
> call this new type of node a 'small node'. The intention is that
> bitcoin-core would eventually ship 'small nodes' by default, such that
> the expected amount of disk consumption drops from today's 100+ GB to
> less than 30 GB.
>
> My alternative proposal has the following properties:
>
> + Full nodes only need to store ~20% of the blockchain
> + With very high probability, a new node will be able to recover the
> entire blockchain by connecting to 6 random small node peers.
> + An attacker that can eliminate a chosen+ 95% of the full nodes
> running today will be unable to prevent new nodes from downloading the
> full blockchain, even if the attacker is also able to eliminate all
> archival nodes. (assuming all nodes today were small nodes instead of
> archival nodes)
>
> Method:
>
> A small node will pick an index [5, 256). This index is that node's
> permanent index. When storing a block, instead of storing the full
> block, the node will use Reed-Solomon coding to erasure code the block
> using a 5-of-256 scheme. The result will be 256 pieces that are 20% of
> the size of the block each. The node picks the piece that corresponds
> to its index, and stores that instead. (Indexes 0-4 are reserved for
> archival nodes - explained later)
>
> The node is now storing a fragment of every block. Alone, this
> fragment cannot be used to recover any piece of the blockchain.
> However, when paired with any 5 unique fragments (fragments of the
> same index will not be unique), the full block can be recovered.
>
> Nodes can optionally store more than 1 fragment each. At 5 fragments,
> the node becomes a full archival node, and the chosen indexes should
> be 0-4. This is advantageous for the archival node as the encoded data
> for the first 5 indexes will actually be identical to the block itself
> - there is no computational overhead for selecting the first indexes.
> There is also no need to choose random indexes, because the full block
> can be recovered no matter which indexes are chosen.
>
> When connecting to new peers, the indexes of each peer needs to be
> known. Once peers totaling 5 unique indexes are discovered, blockchain
> download can begin. Connecting to just 5 small node peers provides a
> >95% chance of getting 5 uniques, with exponentially improving odds of
> success as you connect to more peers. Connecting to a single archive
> node guarantees that any gaps can be filled.
>
> A good encoder should be able to turn a block into a 5-of-256 piece
> set in under 10 milliseconds using a single core on a standard
> consumer desktop. This should not slow down initial blockchain
> download substantially, though the overhead is more than a rounding error.
>
> *DoS Prevention:*
>
> A malicious node may provide garbage data instead of the actual piece.
> Given just the garbage data and 4 other correct pieces, it is
> impossible (best I know anyway) to tell which piece is the garbage piece.
>
> One option in this case would be to seek out an archival node that
> could verify the correctness of the pieces, and identify the malicious
> node.
>
> Another option would be to have the small nodes store a cryptographic
> checksum of each piece. Obtaining the cryptographic checksum for all
> 256 pieces would incur a nontrivial amount of hashing (post segwit, as
> much as 100MB of extra hashing per block), and would require an
> additional ~4kb of storage per block. The hashing overhead here may be
> prohibitive.
>
> Another solution would be to find additional pieces and brute-force
> combinations of 5 until a working combination was discovered. Though
> this sounds nasty, it should take less than five seconds of
> computation to find the working combination given 5 correct pieces and
> 2 incorrect pieces. This computation only needs to be performed once
> to identify the malicious peers.
>
> I also believe that alternative erasure coding schemes exist which
> actually are able to identify the bad pieces given sufficient good
> pieces, however I don't know if they have the same computational
> performance as the best Reed-Solomon coding implementations.
>
> *Deployment:*
>
> Small nodes are completely useless unless the critical mass of 5
> pieces can be obtained. The first version that supports small node
> block downloads should default everyone to an archival node (meaning
> indexes 0-4 are used)
>
> Once there are enough small-node-enabled archive nodes, the default
> can be switched so that nodes only have a single index by default. In
> the first few days, when there are only a few small nodes, the
> previously-deployed archival nodes can help fill in the gaps, and the
> small nodes can be useful for blockchain download right away.
>
> ----------------------------------
>
> This represents a non-trivial amount of code, but I believe that the
> result would be a non-trivial increase in the percentage of users
> running full nodes, and a healthier overall network.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/90387873/attachment-0001.html>

2023-06-07 18:00:19 UTC

- reply

📅 Original date posted:2017-04-20
📝 Original message:??? what do you mean? (https://www.soyoustart.com/fr/serveurs-essential/)
Le 20/04/2017 à 17:50, Erik Aronesty via bitcoin-dev a écrit :
> Try to find 1TB dedicated server hosting ...
>
> If you want to set up an ecommerce site somewhere besides your living
> room, storage costs are still a concern.
>
> On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> 1TB HDD is now available for under $40 USD. How is the 100GB
> storage requirement preventing anyone from setting up full nodes?
>
> On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> *Rationale:*
>
> A node that stores the full blockchain (I will use the term
> archival node) requires over 100GB of disk space, which I
> believe is one of the most significant barriers to more people
> running full nodes. And I believe the ecosystem would benefit
> substantially if more users were running full nodes.
>
> The best alternative today to storing the full blockchain is
> to run a pruned node, which keeps only the UTXO set and throws
> away already verified blocks. The operator of the pruned node
> is able to enjoy the full security benefits of a full node,
> but is essentially leeching the network, as they performed a
> large download likely without contributing anything back.
>
> This puts more pressure on the archival nodes, as the archival
> nodes need to pick up the slack and help new nodes bootstrap
> to the network. As the pressure on archival nodes grows, fewer
> people will be able to actually run archival nodes, and the
> situation will degrade. The situation would likely become
> problematic quickly if bitcoin-core were to ship with the
> defaults set to a pruned node.
>
> Even further, the people most likely to care about saving
> 100GB of disk space are also the people least likely to care
> about some extra bandwidth usage. For datacenter nodes, and
> for nodes doing lots of bandwidth, the bandwidth is usually
> the biggest cost of running the node. For home users however,
> as long as they stay under their bandwidth cap, the bandwidth
> is actually free. Ideally, new nodes would be able to
> bootstrap from nodes that do not have to pay for their
> bandwidth, instead of needing to rely on a decreasing
> percentage of heavy-duty archival nodes.
>
> I have (perhaps incorrectly) identified disk space consumption
> as the most significant factor in your average user choosing
> to run a pruned node or a lite client instead of a full node.
> The average user is not typically too worried about bandwidth,
> and is also not typically too worried about initial blockchain
> download time. But the 100GB hit to your disk space can be a
> huge psychological factor, especially if your hard drive only
> has 500GB available in the first place, and 250+ GB is already
> consumed by other files you have.
>
> I believe that improving the disk usage situation would
> greatly benefit decentralization, especially if it could be
> done without putting pressure on archival nodes.
>
> *Small Nodes Proposal:*
>
> I propose an alternative to the pruned node that does not put
> undue pressure on archival nodes, and would be acceptable and
> non-risky to ship as a default in bitcoin-core. For lack of a
> better name, I'll call this new type of node a 'small node'.
> The intention is that bitcoin-core would eventually ship
> 'small nodes' by default, such that the expected amount of
> disk consumption drops from today's 100+ GB to less than 30 GB.
>
> My alternative proposal has the following properties:
>
> + Full nodes only need to store ~20% of the blockchain
> + With very high probability, a new node will be able to
> recover the entire blockchain by connecting to 6 random small
> node peers.
> + An attacker that can eliminate a chosen+ 95% of the full
> nodes running today will be unable to prevent new nodes from
> downloading the full blockchain, even if the attacker is also
> able to eliminate all archival nodes. (assuming all nodes
> today were small nodes instead of archival nodes)
>
> Method:
>
> A small node will pick an index [5, 256). This index is that
> node's permanent index. When storing a block, instead of
> storing the full block, the node will use Reed-Solomon coding
> to erasure code the block using a 5-of-256 scheme. The result
> will be 256 pieces that are 20% of the size of the block each.
> The node picks the piece that corresponds to its index, and
> stores that instead. (Indexes 0-4 are reserved for archival
> nodes - explained later)
>
> The node is now storing a fragment of every block. Alone, this
> fragment cannot be used to recover any piece of the
> blockchain. However, when paired with any 5 unique fragments
> (fragments of the same index will not be unique), the full
> block can be recovered.
>
> Nodes can optionally store more than 1 fragment each. At 5
> fragments, the node becomes a full archival node, and the
> chosen indexes should be 0-4. This is advantageous for the
> archival node as the encoded data for the first 5 indexes will
> actually be identical to the block itself - there is no
> computational overhead for selecting the first indexes. There
> is also no need to choose random indexes, because the full
> block can be recovered no matter which indexes are chosen.
>
> When connecting to new peers, the indexes of each peer needs
> to be known. Once peers totaling 5 unique indexes are
> discovered, blockchain download can begin. Connecting to just
> 5 small node peers provides a >95% chance of getting 5
> uniques, with exponentially improving odds of success as you
> connect to more peers. Connecting to a single archive node
> guarantees that any gaps can be filled.
>
> A good encoder should be able to turn a block into a 5-of-256
> piece set in under 10 milliseconds using a single core on a
> standard consumer desktop. This should not slow down initial
> blockchain download substantially, though the overhead is more
> than a rounding error.
>
> *DoS Prevention:*
>
> A malicious node may provide garbage data instead of the
> actual piece. Given just the garbage data and 4 other correct
> pieces, it is impossible (best I know anyway) to tell which
> piece is the garbage piece.
>
> One option in this case would be to seek out an archival node
> that could verify the correctness of the pieces, and identify
> the malicious node.
>
> Another option would be to have the small nodes store a
> cryptographic checksum of each piece. Obtaining the
> cryptographic checksum for all 256 pieces would incur a
> nontrivial amount of hashing (post segwit, as much as 100MB of
> extra hashing per block), and would require an additional ~4kb
> of storage per block. The hashing overhead here may be
> prohibitive.
>
> Another solution would be to find additional pieces and
> brute-force combinations of 5 until a working combination was
> discovered. Though this sounds nasty, it should take less than
> five seconds of computation to find the working combination
> given 5 correct pieces and 2 incorrect pieces. This
> computation only needs to be performed once to identify the
> malicious peers.
>
> I also believe that alternative erasure coding schemes exist
> which actually are able to identify the bad pieces given
> sufficient good pieces, however I don't know if they have the
> same computational performance as the best Reed-Solomon coding
> implementations.
>
> *Deployment:*
>
> Small nodes are completely useless unless the critical mass of
> 5 pieces can be obtained. The first version that supports
> small node block downloads should default everyone to an
> archival node (meaning indexes 0-4 are used)
>
> Once there are enough small-node-enabled archive nodes, the
> default can be switched so that nodes only have a single index
> by default. In the first few days, when there are only a few
> small nodes, the previously-deployed archival nodes can help
> fill in the gaps, and the small nodes can be useful for
> blockchain download right away.
>
> ----------------------------------
>
> This represents a non-trivial amount of code, but I believe
> that the result would be a non-trivial increase in the
> percentage of users running full nodes, and a healthier
> overall network.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170421/4b1d9383/attachment-0001.html>

2023-06-07 17:58:18 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:Well it's not going off-topic since the btc folks need now to find a way
to counter the attack
The disk space story is know to be a non issue, because encouraging
people to run nodes while they don't know how to dedicate the right
storage space that is trivial and not expensive to get today is just
stupid, they should not try to run full nodes, and no I tested with non
SSD drives, I was more wondering about cpu and bandwidth use, but did
not notice any impact, just stopped because a repeated sw bug or drive
issue desynched the chain and bitcoin-qt was trying to reload it from
the begining each time, which in my case was taking 10 days despite of
good bandwidth (which would allow me to torrent the entire chain + state
in less than 20 hours), so I stopped after the 3rd crash, setting up a
full node on my servers is still in the todo list (very low priority for
the reasons already explained)
Running a prune node implies first to setup a full node, so the same
problematic applies and then the advantage of pruning is not really
obvious, I don't know what's the strange story about "archival nodes", I
proposed something else
Back to the topic, the conclusion is that this is not difficult at all
for many people to run efficient full nodes, ideally the community
should promote this, seed a torrent with a recent state, implement a
patch to defeat BU plans and have everybody upgrade
But of course this will not happen
Le 29/03/2017 à 18:41, Andrew Johnson a écrit :
> I believe that as we continue to add users to the system by scaling
> capacity that we will see more new nodes appear, but I'm at a bit of a
> loss as to how to empirically prove it.
>
> I do see your point on increasing load on archival nodes, but the
> majority of that load is going to come from new nodes coming online,
> they're the only ones going after very old blocks. I could see that
> as a potential attack vector, overwhelm the archival nodes by spinning
> up new nodes constantly, therefore making it difficult for a "real"
> new node to get up to speed in a reasonable amount of time.
>
> Perhaps the answer there would be a way to pay an archival node a
> small amount of bitcoin in order to retrieve blocks older than a
> certain cutoff? Include an IP address for the node asking for the
> data as metadata in the transaction... Archival nodes could set and
> publish their own policy, let the market decide what those older
> blocks are worth. Would also help to incentivize running archival
> node, which we do need. Of course, this isn't very user friendly.
>
> We can take this to bitcoin-discuss, if we're getting too far off topic.
>
>
> On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick at gmail.com
> <mailto:david.vorick at gmail.com>> wrote:
>
>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson"
> <andrew.johnson83 at gmail.com <mailto:andrew.johnson83 at gmail.com>>
> wrote:
>
> What's stopping these users from running a pruned node? Not
> every node needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the
> default configuration then I think you would see far more users
> running a pruned node.
>
> But that would also substantially increase the burden on archive
> nodes.
>
>
> Further discussion about disk space requirements should be taken
> to another thread.
>
>
> --
> Andrew Johnson
>
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/0b5f83cc/attachment.html>

2023-06-07 17:58:15 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:I have heard such theory before, it's a complete mistake to think that
others would run full nodes to protect their business and then yours,
unless it is proven that they are decentralized and independent
Running a full node is trivial and not expensive for people who know how
to do it, even with much bigger blocks, assuming that the full nodes are
still decentralized and that they don't have to fight against big nodes
who would attract the traffic first
I have posted many times here a small proposal, that exactly describes
what is going on now, yes miners are nodes too... it's disturbing to see
that despite of Tera bytes of BIPs, papers, etc the current situation is
happening and that all the supposed decentralized system is biased by
centralization
Do we know what majority controls the 6000 full nodes?
Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :
> > Perhaps you are fortunate to have a home computer that has more than
> a single 512GB SSD. Lots of consumer hardware has that little storage.
>
> That's very poor logic, sorry. Restricted-space SSD's are not a
> cost-effective hardware option for running a node. Keeping blocksizes
> small has significant other costs for everyone. Comparing the cost of
> running a node under arbitrary conditons A, B, or C when there are far
> more efficient options than any of those is a very bad way to think
> about the costs of running a node. You basically have to ignore the
> significant consequences of keeping blocks small.
>
> If node operational costs rose to the point where an entire wide swath
> of users that we do actually need for security purposes could not
> justify running a node, that's something important for consideration.
> For me, that translates to modern hardware that's relatively well
> aligned with the needs of running a node - perhaps budget hardware,
> but still modern - and above-average bandwidth caps.
>
> You're free to disagree, but your example only makes sense to me if
> blocksize caps didn't have serious consequences. Even if those
> consequences are just the threat of a contentious fork by people who
> are mislead about the real consequences, that threat is still a
> consequence itself.
>
> On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Perhaps you are fortunate to have a home computer that has more
> than a single 512GB SSD. Lots of consumer hardware has that little
> storage. Throw on top of it standard consumer usage, and you're
> often left with less than 200 GB of free space. Bitcoin consumes
> more than half of that, which feels very expensive, especially if
> it motivates you to buy another drive.
>
> I have talked to several people who cite this as the primary
> reason that they are reluctant to join the full node club.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/c54aa76d/attachment-0001.html>

2023-06-07 17:58:12 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:Le 29/03/2017 à 11:16, Jared Lee Richardson via bitcoin-dev a écrit :
> Nodes process transactions and are paid nothing to do so, and their
> costs are 100x more relevant to the blocksize debate than a paper
> about miner costs.
>
> Miners are rewarded with fees; nodes are rewarded only by utility and
> price increases.
Nodes are rewarded by just nothing which is the main problem of the
bitcoin network (who is therefore not a decentralized system today)
although it seems like everybody is eluding the issue (as well as how to
find solutions to setup quickly full nodes as you quoted in another
answer to this thread, and of course design a decentralized system to
make sure that full nodes behave correctly)
Bitcoin would not be in this situation (ie maybe at the mercy of a very
small minority of freeriders among all the entities involved in the
network, ie miners, just seeking to make more and more money because
they invested in an anti-ecological pow, not understanding that bitcoin
is not just about money) if more nodes were existing and could reject
their blocks
It seems like the initial message of this thread(t) is an ultimatum:
whether you implement what we ask, whether we join BU and then > 50 is
almost reached...
>
> On Tue, Mar 28, 2017 at 10:53 AM, Alphonse Pace via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Juan,
>
> I suggest you take a look at this
> paper: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
> <http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf> It may help you
> form opinions based in science rather than what appears to be
> nothing more than a hunch. It shows that even 4MB is unsafe.
> SegWit provides up to this limit.
>
> 8MB is most definitely not safe today.
>
> Whether it is unsafe or impossible is the topic, since Wang Chun
> proposed making the block size limit 32MiB.
>
>
> Wang Chun,
>
> Can you specify what meeting you are talking about? You seem to
> have not replied on that point. Who were the participants and
> what was the purpose of this meeting?
>
> -Alphonse
>
> On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg at 112bit.com
> <mailto:jg at 112bit.com>> wrote:
>
> Alphonse,
>
>
>
> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on
> 2016 and 32MB limit valid in next halving, from network,
> storage and CPU perspective or 1MB was too high in 2010 what
> is possible or 1MB is to low today.
>
>
>
> If is unsafe or impossible to raise the blocksize is a
> different topic.
>
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> *From:*bitcoin-dev-bounces at lists.linuxfoundation.org
> <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>
> [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org
> <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>] *On
> Behalf Of *Alphonse Pace via bitcoin-dev
> *Sent:* Tuesday, March 28, 2017 2:24 PM
> *To:* Wang Chun <1240902 at gmail.com
> <mailto:1240902 at gmail.com>>; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last
> week's meeting
>
>
>
> What meeting are you referring to? Who were the participants?
>
>
>
> Removing the limit but relying on the p2p protocol is not
> really a true 32MiB limit, but a limit of whatever transport
> methods provide. This can lead to differing consensus if
> alternative layers for relaying are used. What you seem to be
> asking for is an unbound block size (or at least determined by
> whatever miners produce). This has the possibility (and even
> likelihood) of removing many participants from the network,
> including many small miners.
>
>
>
> 32MB in less than 3 years also appears to be far beyond limits
> of safety which are known to exist far sooner, and we cannot
> expect hardware and networking layers to improve by those
> amounts in that time.
>
>
>
> It also seems like it would be much better to wait until
> SegWit activates in order to truly measure the effects on the
> network from this increased capacity before committing to any
> additional increases.
>
>
>
> -Alphonse
>
>
>
>
>
>
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I've proposed this hard fork approach last year in Hong
> Kong Consensus
> but immediately rejected by coredevs at that meeting,
> after more than
> one year it seems that lots of people haven't heard of it.
> So I would
> post this here again for comment.
>
> The basic idea is, as many of us agree, hard fork is risky
> and should
> be well prepared. We need a long time to deploy it.
>
> Despite spam tx on the network, the block capacity is
> approaching its
> limit, and we must think ahead. Shall we code a patch
> right now, to
> remove the block size limit of 1MB, but not activate it
> until far in
> the future. I would propose to remove the 1MB limit at the
> next block
> halving in spring 2020, only limit the block size to 32MiB
> which is
> the maximum size the current p2p protocol allows. This
> patch must be
> in the immediate next release of Bitcoin Core.
>
> With this patch in core's next release, Bitcoin works just
> as before,
> no fork will ever occur, until spring 2020. But everyone
> knows there
> will be a fork scheduled. Third party services, libraries,
> wallets and
> exchanges will have enough time to prepare for it over the
> next three
> years.
>
> We don't yet have an agreement on how to increase the
> block size
> limit. There have been many proposals over the past years,
> like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248,
> BU, and so
> on. These hard fork proposals, with this patch already in
> Core's
> release, they all become soft fork. We'll have enough time
> to discuss
> all these proposals and decide which one to go. Take an
> example, if we
> choose to fork to only 2MB, since 32MiB already scheduled,
> reduce it
> from 32MiB to 2MB will be a soft fork.
>
> Anyway, we must code something right now, before it
> becomes too late.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/a4a9932b/attachment-0001.html>

2023-06-07 17:58:06 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:Le 29/03/2017 à 17:57, David Vorick via bitcoin-dev a écrit :
> It's too expensive for a home user to run a full node, and user-run
> full nodes are what provide the strongest defence against political
> manuveuring.
Yes but what makes you think that "It's too expensive for a home user to
run a full node" ? Not trivial, maybe, long to setup, for sure, but why
"expensive"? I tested running a full node from home that was normally
correctly configured and did not notice anything annoying/expensive
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 17:56:39 UTC

- reply

📅 Original date posted:2017-02-24
📝 Original message:??? apparently we are not discussing the same thing
Maybe I did not provide the right links (reading them again I myself
don't find them so clear), see maybe again
https://github.com/whatwg/streams/issues/33#issuecomment-28045860
a - b - c -d
hash(a)
hash(a+b)
etc
But you are not going to rehash from the beginning, then:
update a --> keep the remaining bytes a_ (+ hash state 1) --> digest
a=hash(a)
update a_+b from hash state 1--> keep the remaining bytes b_ (+ hash
state 2) --> digest a_+b=hash(a+b)
etc
Basically that's similar to a real time progressive hash of chunks of a
file that you are streaming and therefore don't know what will come next
(per opposition to hashing a file that you already have), this could
apply to trees
This is different from something like:
hash(a)
hash(hash(a) +hash(b))
etc
There is no initial state, and the attacker can't modify what was
already hashed, to make it more difficult you can probably modify the
hash state N
Le 24/02/2017 à 17:30, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> Not sure that you really read deeply what I sent, because stating
>> that
>> hashing files continuously instead of hashing the intermediate steps
>> just gives more latitude to the attacker can't be true when the
>> attacker
>> has absolutely no control over the past files
> What prevents the attacker to provide different past files when talking
> to parties who are still in the initial state?
>
> Then the question is: knowing the hash state, is it as easy to find a
>> collision between two files that will be computed in the next round
>> than
>> finding a collision between two files only?
> With the original usage of the hash function, the hash state is always
> the initial state. Now that the attacker has some control over the hash
> state even. In other words, if the original use of the hash function
> was vulnerable, then your scheme is vulnerable for the initial state.
>
> Concrete attack: If you can find x != y with H(x) = H(y), then you can
> also find m, x != y, with H(m||x) = H(m||y), just by setting m = "".
>
> Not sure if this is the right place to discuss that issue though...
>
> Best,
> Tim
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 17:56:38 UTC

- reply

📅 Original date posted:2017-02-24
📝 Original message:Not sure that you really read deeply what I sent, because stating that
hashing files continuously instead of hashing the intermediate steps
just gives more latitude to the attacker can't be true when the attacker
has absolutely no control over the past files
I did not write this as a workaround to fix SHA1, which will be dead
soon or later but as maybe some general concept that could possibly help
whatever hash function you are using for objects that are not frozen but
extending (ie the original email stating that trees might be some kind
of worse candidates for collisions reminded me this), indeed it makes no
sense to patch SHA1 or play around, but this kind of proposal could
accompany the defunct
The drawback is that you have to keep the hash state when you close the
latest hash computation in order to start the next one
Then the question is: knowing the hash state, is it as easy to find a
collision between two files that will be computed in the next round than
finding a collision between two files only?
Knowing that you can probably modify the hash state with some
unpredictable patterns
Most likely the answer is: no, it's (astronomically?) more difficult
Please take it as a suggestion that might be explored (ps: I have the
code for this if needed) rather than an affirmation, still amazed as
shown in the few links provided (among others) that each time I raise
this subject nobody really pays attention (what's the use case?, etc)
and by the fact that it's apparently used by only one project in the
world and not supported by any library
Le 24/02/2017 à 11:04, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> I have not worked on this since some time, so that's just thoughts,
>> but maybe it can render things much more difficult
>> than computing two files until the same hash is found
>>
> You basically rely on the idea that specific collisions are more
> difficult to find. This trick or similar tricks will not help. (And
> actually, the more files you add to the hash, the more freedom you give
> the attacker.)
>
> Even if certain collisions are more difficult to find today (which is
> certainly true), the general rule is that someone will prove you wrong
> in a year.
>
> Even if ignore security entirely, switching to new hash function is
> much simpler trying to fix the usage of a broken hash function.
>
> Relying on SHA1 is hopeless. We have to get rid of it.
>
> Best,
> Tim
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 17:56:38 UTC

- reply

📅 Original date posted:2017-02-23
📝 Original message:Maybe not, unlike frozen objects (certificates, etc), trees are supposed
to extend
Then you can perform progressive hash operations on the objects, ie
instead of hashing the intermediate hash of the objects you do it
continuously (ie instead of hashing the hash of hash file a + hash file
b + hash file c, wait for file d and then do the same, instead hash(file
a + file b + file c), when d comes compute the hash of (file a + file b
+ file c + file d), which implies each time to keep the intermediary
hash state because you are not going to recompute everything from the
beginning)
I have not worked on this since some time, so that's just thoughts, but
maybe it can render things much more difficult than computing two files
until the same hash is found
The only living example I know implementing this is the Tor protocol,
fact apparently unknown, this is probably why nobody cares and nobody is
willing to take it into account (please follow bwd/fwd [1] and see [2]),
this is not existing in any crypto implementations, unless you hack into
it, and this applies to progressive encryption too
[1]
https://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0018.html
[2] https://github.com/whatwg/streams/issues/33#issuecomment-28554151
Le 23/02/2017 à 22:28, Peter Todd via bitcoin-dev a écrit :
> On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wrote:
>> Worth noting: the impact of the SHA1 collison attack on Git is *not* limited
>> only to maintainers making maliciously colliding Git commits, but also
>> third-party's submitting pull-reqs containing commits, trees, and especially
>> files for which collisions have been found. This is likely to be exploitable in
>> practice with binary files, as reviewers aren't going to necessarily notice
>> garbage at the end of a file needed for the attack; if the attack can be
>> extended to constricted character sets like unicode or ASCII, we're in trouble
>> in general.
>>
>> Concretely, I could prepare a pair of files with the same SHA1 hash, taking
>> into account the header that Git prepends when hashing files. I'd then submit
>> that pull-req to a project with the "clean" version of that file. Once the
>> maintainer merges my pull-req, possibly PGP signing the git commit, I then take
>> that signature and distribute the same repo, but with the "clean" version
>> replaced by the malicious version of the file.
> Thinking about this a bit more, the most concerning avenue of attack is likely
> to be tree objects, as I'll bet you you can construct tree objs with garbage at
> the end that many review tools don't pick up on. :(
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170224/7bfa2399/attachment.html>

2023-06-07 17:54:57 UTC

- reply

📅 Original date posted:2016-12-15
📝 Original message:Maybe there are still some advantages but I don't know why this is not
considered as a major issue by the bitcoin community for the future and
why this looks to be never discussed:
- the size of the bitcoin network in terms of full nodes is ridiculous
and this is continuously decreasing, we cannot consider the bitcoin
network as a decentralized p2p network, what you are proposing is
logical but will of course amplify the problem
>For reasons I am unable to determine a significant number of node
operators do not upgrade their clients.
Why should they? What is the incentive for people to run full nodes and
upgrade? FYI I am part of the 2071 0.13.1 nodes for some good reasons
but will just shut it down when I am done, same for zcash (which as a
matter of fact I upgraded today since by some chance I noticed some
updates I was not aware of neither notified, just running it because I
need it from time to time and just don't kill it so I don't have to wait
for the restart process, maybe others are doing the same or just forgot
that they were running a full node)
Because, again, why should I or we maintain it/them?
I have looked at the proposals in the past (as well as the incentive
program) to reward those that are running full nodes but only found a
very few, never implemented (or even considered)
This is the very same for proposals allowing to start a full node from
zero in an acceptable timeframe (ie not 10 days in my case)
If the consensus is not to solve those two points and have a bitcoin
network controlled then it would be interesting to know why, so people
don't waste time trying to find solutions
Satoshi himself predicted that the full nodes will get centralized, I
think it's wrong, or in that case the bitcoin network cannot pretend to
be a decentralized immutable system (can be compared then to the Tor
network which does not pretend to be decentralized, because it is
centralized, and in addition does not encourage small nodes)
PS: IMHO the email notificiation system makes it difficult to follow
whom is answering to whom/what on this list compared to other lists
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms