Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

[Jeremy via bitcoin-dev]

Hey there!

Thanks for your response!

One of the reasons to pick a longer window of, say, a couple difficulty
periods would be that you can make participation in the pool hedge you
against hashrate changes.

You're absolutely spot on to think about the impact of pooling w.r.t.
variance when fees > subsidy. That's not really in the analysis I had in
the (old) post, but when the block revenues swing, dcfmp over longer
periods can really smooth out the revenues for miners in a great way. This can
also help with the "mind the gap" problem when there isn't a backlog of
transactions, since producing an empty block still has some value (in order
to incentivize mining transaction at all and not cheating, we need to
reward txn inclusion as I think you're trying to point out.

Sadly, I've read the rest of your email a couple times and I don't really
get what you're proposing at all. It jumps right into "things you could
compute". Can you maybe try stating the goals of your payout function, and
then demonstrate how what you're proposing meets that? E.g., we want to pay
more to miners that do x?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

[vjudeu via bitcoin-dev]

> how to select an analyze the choice of window
Currently, we need 100 blocks to spend the coinbase transaction and I think 
that should be our "window".
> and payout functions
Something like "miner-based difficulty" should do the trick. So, each miner is 
trying to produce its own block, with its own transactions, and its own 
coinbase reward (based on those transactions, if we want to think ahead and do 
it right from the start, we should be ready for situation where the basic block 
reward is zero and the whole coinbase is based only on transaction fees). So, 
each miner can mine a block with its own coinbase amount (based on transaction 
fees). Then, that miner should multiply the target by the number of satoshis 
collected in the coinbase transaction to get "target per satoshi". Then, by 
dividing this target by its block hash, it would produce the number of satoshis 
that miner should receive.
Some example:
difficulty: 170ba21f
target: 000ba21f
coinbase: 6.27930034 BTC (627930034 satoshis = 0x256d73b2 satoshis)
targetPerSatoshi: 
000ba21f*0x256d73b2
targetPerSatoshi: 
0001b367c41da68e
sampleShare: b613738816247a7f4d357cae555996519cf5b543e9b3554b
minerReward: targetPerSatoshi/sampleShare=0x2642e (156718 satoshis = 0.00156718 
BTC for this share)
Because we assume that the basic reward will be zero, we assume that all miners 
will include their own set of transactions. That means, to check if the miner 
really should receive that reward, checking all transactions is required. 
Assuming that most of the miners will have similar transactions in their 
mempools, for each share there is a need to only check transactions that were 
unknown by that miner. For all other previously validated transactions, miners 
can store a table like: " " and then quickly validate if the amount 
specified in the coinbase transaction is correct.
To avoid "share spam", we can use something like "miner-based difficulty" 
mentioned above. Everyone knows the network difficulty, but not all miners are 
directly connected. So, for each connection with each miner in our 
decentralized pool, we can define a difficulty for each connection. In this 
way, each node can specify the absolute minimum difficulty, where paying any 
reward is above the dust limit, and where including that miner makes sense. 
Then, each miner can produce shares and adjust miner-based difficulty, just to 
produce for example one share per 10 minutes (or per 30 seconds if we have 
enough resources to fully validate each share from each miner we are connected 
with in that time).
If we want to include really small miners (like CPU miners), then we need a way 
to allow sub-satoshi payments. That means, each small miner should mine to a 
single N-of-N taproot-based multisig, where the whole pot is then splitted 
between N miners in LN. That means, for example one output of 1000 satoshis can 
be shared between one million small CPU miners. Then, our target from example 
above is denominated in millisatoshis.
targetPerSatoshi: 
0001b367c41da68e*0x3e8 (1000 in 
decimal)
targetPerMillisatoshi: 
06a4cd5613d29ab0
On 2021-12-12 17:43:39 user Jeremy via bitcoin-dev 
 wrote:
Howdy, welcome to day 15!
 
Today's post covers a form of a mining pool that can be operated as sort of a 
map-reduce over blocks without any "infrastructure".
 
https://rubin.io/bitcoin/2021/12/12/advent-15/
 
There's still some really open-ended questions (perhaps for y'all to consider) 
around how to select an analyze the choice of window and payout functions, but 
something like this could alleviate a lot of the centralization pressures 
typically faced by pools.
 
Notably, compared to previous attempts, combining the payment pool payout with 
this concept means that there is practically very little on-chain overhead from 
this approach as the chain-load
for including payouts in every block is deferred for future cooperation among 
miners. Although that can be considered cooperation itself, if you think of it 
like a pipeline, the cooperation happens out of band from mining and block 
production so it really is coordination free to mine.
 
Cheers,
 
Jeremy
--
@JeremyRubin___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[damian--- via bitcoin-dev]

Good Afternoon,

You are right, of course, I did nothing to differentiate between the 
privacy of the connection of the node, the identification of the public 
IP of the node, and the suspected original of a transaction.


If I understand, the reason for only the originating node to rebroadcast 
was because only that node can be authoritative,  but that logic is 
fallible once the transaction is signed - none of the nodes apart from 
the origin know about the transaction but they always manage to gossip.


Anyway, it is concept ACK from me and I know it has been a concern that 
I have raised previously, I presume some pseudo-random and lengthening 
per attempt length of time between receiving gossip about a transaction 
and rebroadcasting attempts. I have always worked with 
`mempoolexpiry=2160` and `maxmempool=900` and so far as I can presume 
mempool has never been full.


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
duigco.org DUIGCO API
and other projects


m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this 
email if misdelivered.

On 2021-12-11 08:21, Pieter Wuille via bitcoin-dev wrote:

It is that the solution to privacy is to use privacy-enhancing network
communications, such as TOR. I am not against a mechanism to 
rebroadcast

transactions more robustly if the mempool of adjoining nodes has
forgotten about them, but the truth is, all transactions originate 
from

some node, and there are methods that allow an individual node to be
identified as the likely source of a transaction unless 
privacy-enabled

networks are utilised. Having a different method to cause rebroadcast
does not obfuscate the origin.


You're talking about distinct aspects of transaction privacy.

The rebroadcasting approach as it exists on the network, where wallets
are responsible for their own rebroadcasting, directly reveals to your
peers a relation between nodes and transactions: whenever any node
relays the same transaction twice, it almost certainly implies they
are the origin.

This is just a node-transaction relation, and not necessarily
IP-transaction relation. The latter can indeed be avoided by only
connecting over Tor, or using other privacy networks, but just hiding
the relation with IP addresses isn't sufficient (and has its own
downsides; e.g. Tor-only connectivity is far more susceptible to
partition/Eclipse/DoS attacks). For example seeing the same node (even
without knowing its IP) rebroadcast two transaction lets an observe
infer a relation between those transactions, and that too is a privacy
leak.

I believe moving to a model where mempools/nodes themselves are
responsible for rebroadcasting is a great solution to improving this
specific problem, simply because if everyone rebroadcasts, the
original author doing it too does not stand out anymore. It isn't
"fixing privacy", it's fixing a specific leak, one of many, but this
isn't a black and white property.

Cheers,

--
Pieter

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[Prayank via bitcoin-dev]

Hi Aymeric,
> What I am proposing since years, not only to bitcoin, is to use the Tor
protocol independently of the Tor network, and from the browsers alsoacting as 
nodes (not to be misunderstood with the Tor Browser, this hasnothing to do) 
probably someone one day will understand it
I understand the concept and like it. However had some issues with use of 
JavaScript and WebRTC which were partially answered in 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019373.html

I like that you don't give up, passionate about privacy, nodes and contributing 
to Bitcoin. Not sure if you have commits in Bitcoin Core repository which is 
one of the weird requirements to get free tickets for open source stage of 
https://b.tc/conference/

I think presenting your idea with some demo, talking to other developers in 
community IRL would help your project. If you agree and interested to 
participate, please apply here: https://b.tc/conference/open-source

I have already requested few people and recommend you to share things about 
your project in conference. Let me know if you need sponsors for flight tickets 
as well.

Happy Weekend!
-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[Pieter Wuille via bitcoin-dev]

On Sunday, December 12th, 2021 at 9:23 AM, Aymeric Vitte via bitcoin-dev 
 wrote:

> Using the Tor network to bypass censorship for bitcoin can work but is a very 
> poor solution, the Tor network is very centralized, very small, watched and 
> controlled, with plenty of features that do not apply to other protocols than 
> those made to be used with the Tor Browser, Pieter gave a simple example, 
> that you can solve easily changing the circuits, the problem remains that you 
> really need to be a super expert to escape all the dangers of the Tor 
> network, not even sure it's possible unless you use something else than the 
> Tor project code

FWIW, I wasn't talking about anything related to Tor's protocol or organization 
at all. What I meant is that because creating a hidden service has ~0 cost, it 
is trivial for anyone to spin up an arbitrary number of Bitcoin hidden 
services. Thus, if one runs a node that only connects to hidden services, it is 
fairly easily eclipsable.

It's just one example of a downside of (a particular way of) using Tor. That 
doesn't mean I recommend against using Tor for Bitcoin traffic at all; my point 
was simply that there are trade-offs, and aspects of privacy of the P2P 
protocol that Tor does not address, and thus one shouldn't assume that all 
problems are solved by "just use Tor".

Cheers,

--
Pieter___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

[Jeremy via bitcoin-dev]

Howdy, welcome to day 15!

Today's post covers a form of a mining pool that can be operated as sort of
a map-reduce over blocks without any "infrastructure".

https://rubin.io/bitcoin/2021/12/12/advent-15/

There's still some really open-ended questions (perhaps for y'all to
consider) around how to select an analyze the choice of window and payout
functions, but something like this could alleviate a lot of the
centralization pressures typically faced by pools.

Notably, compared to previous attempts, combining the payment pool payout
with this concept means that there is practically very little on-chain
overhead from this approach as the chain-load
for including payouts in every block is deferred for future cooperation
among miners. Although that can be considered cooperation itself, if you
think of it like a pipeline, the cooperation happens out of band from
mining and block production so it really is coordination free to mine.


Cheers,

Jeremy

--
@JeremyRubin 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[Aymeric Vitte via bitcoin-dev]

Using the Tor network to bypass censorship for bitcoin can work but is a
very poor solution, the Tor network is very centralized, very small,
watched and controlled, with plenty of features that do not apply to
other protocols than those made to be used with the Tor Browser, Pieter
gave a simple example, that you can solve easily changing the circuits,
the problem remains that you really need to be a super expert to escape
all the dangers of the Tor network, not even sure it's possible unless
you use something else than the Tor project code

Believe it or not, node-Tor is a more than ten years old project (and
not a duplicate of the Tor network), so I know what I am talking about,
different studies of mine show also that the more you try to hide the
more you can get caught, even on really decentralized networks like
bittorrent, unlike another common belief that in such big networks it's
difficult to track/deanonymize peers, it is not

Extra measures like rebroadcasting can maybe add something, but back to
the previous sentence, extra measures can also help to catch/track you
if not well designed/thought

What I am proposing since years, not only to bitcoin, is to use the Tor
protocol independently of the Tor network, and from the browsers also
acting as nodes (not to be misunderstood with the Tor Browser, this has
nothing to do) probably someone one day will understand it

Le 12/12/2021 à 14:38, Karl a écrit :
>
>
> On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev
>  > wrote:
>
> Indeed, I reiterate that using the Tor network for Bitcoin or
> whatever protocol not related to the Tor Browser (ie browsing and
> HS) does not make sense, for plenty of reasons
>
>
> Please cite this.  It is very hard to believe.
>
> Personally, I have encountered network blocking of bitcoin peers, and
> Tor is one way to reconnect with the network when this happens.
>
>
> Regardless, reasonable rebroadcasting of nonlocal transactions is a
> hands-down good thing.  This does not make them anonymous, but it does
> make it a little harder to track their origin, and additionally it
> makes their transmission more robust.
>
> Every extra measure is a good thing, as everything eventually fails.
>

-- 
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
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
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: 
http://torrent-live.peersm.com
Peersm : http://www.peersm.com

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[Karl via bitcoin-dev]

On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Indeed, I reiterate that using the Tor network for Bitcoin or whatever
> protocol not related to the Tor Browser (ie browsing and HS) does not make
> sense, for plenty of reasons
>

Please cite this.  It is very hard to believe.

Personally, I have encountered network blocking of bitcoin peers, and Tor
is one way to reconnect with the network when this happens.


Regardless, reasonable rebroadcasting of nonlocal transactions is a
hands-down good thing.  This does not make them anonymous, but it does make
it a little harder to track their origin, and additionally it makes their
transmission more robust.

Every extra measure is a good thing, as everything eventually fails.

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[Aymeric Vitte via bitcoin-dev]

Indeed, I reiterate that using the Tor network for Bitcoin or whatever
protocol not related to the Tor Browser (ie browsing and HS) does not
make sense, for plenty of reasons

But using the Tor protocol outside of the Tor network (and inside
browsers for wallets for example) does:
https://github.com/Ayms/node-Tor#presentation and
https://github.com/Ayms/node-Tor#phase-4-and-phase-5, anonymizing nodes
can just be already existing bitcoin nodes, example:
https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853


Le 11/12/2021 à 17:21, Pieter Wuille via bitcoin-dev a écrit :
>> It is that the solution to privacy is to use privacy-enhancing network
>> communications, such as TOR. I am not against a mechanism to rebroadcast
>> transactions more robustly if the mempool of adjoining nodes has
>> forgotten about them, but the truth is, all transactions originate from
>> some node, and there are methods that allow an individual node to be
>> identified as the likely source of a transaction unless privacy-enabled
>> networks are utilised. Having a different method to cause rebroadcast
>> does not obfuscate the origin.
> You're talking about distinct aspects of transaction privacy.
>
> The rebroadcasting approach as it exists on the network, where wallets are 
> responsible for their own rebroadcasting, directly reveals to your peers a 
> relation between nodes and transactions: whenever any node relays the same 
> transaction twice, it almost certainly implies they are the origin.
>
> This is just a node-transaction relation, and not necessarily IP-transaction 
> relation. The latter can indeed be avoided by only connecting over Tor, or 
> using other privacy networks, but just hiding the relation with IP addresses 
> isn't sufficient (and has its own downsides; e.g. Tor-only connectivity is 
> far more susceptible to partition/Eclipse/DoS attacks). For example seeing 
> the same node (even without knowing its IP) rebroadcast two transaction lets 
> an observe infer a relation between those transactions, and that too is a 
> privacy leak.
>
> I believe moving to a model where mempools/nodes themselves are responsible 
> for rebroadcasting is a great solution to improving this specific problem, 
> simply because if everyone rebroadcasts, the original author doing it too 
> does not stand out anymore. It isn't "fixing privacy", it's fixing a specific 
> leak, one of many, but this isn't a black and white property.
>
> Cheers,
>
> --
> Pieter
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev