Raúl Martínez [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 15:25:18

- reply

📅 Original date posted:2014-08-19
📝 Original message:Hi,
I believe that all comunications should be encrypted by default, no matter
that is public information (tx info), the only exception I would make would
be block packets (to avoid increasing propagation time).
I suggest that Bitcoin Core should generate a public/private key pair and
share the public one with peers.
This could provide privacy and integrity but not autentication.
This way you can impersonate a bitcoin node (active mitm) but you cant just
be passive and record all transactions send or recieved by an IP address.
Today you can just watch for incoming/outgoing transactions to determine
what tx are created in the Node, when you find one you can see the Bitcoin
address inputs and outputs and track that person's bitcoins.
As an example, SSH provides this kind of encryption, althogh Bitcoin Core
should ignore fingerprint changes (caused due to reinstalls).
Please feel free to disqus why this is not needed or why you like this idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/0538ac1f/attachment.html>

2023-06-07 15:25:18

- reply

📅 Original date posted:2014-08-19
📝 Original message:Only messages between peers are encrypted, only during transit.
Before sending a transaction to Node B you use his public key, so Node B
has the key
El 19/08/2014 17:05, "Richard Moore" <me at ricmoo.com> escribió:
> If you encrypt all messages with an asymmetric cipher, how would each node
> make use of the blockchain in an encrypted form? Each node would be able to
> encrypt the data, but only the Bitcoin Core Dev could decrypt it?
>
>
> On Aug 19, 2014, at 5:49 AM, Raúl Martínez <rme at i-rme.es> wrote:
>
> Hi,
> I believe that all comunications should be encrypted by default, no matter
> that is public information (tx info), the only exception I would make would
> be block packets (to avoid increasing propagation time).
>
> I suggest that Bitcoin Core should generate a public/private key pair and
> share the public one with peers.
>
> This could provide privacy and integrity but not autentication.
>
> This way you can impersonate a bitcoin node (active mitm) but you cant
> just be passive and record all transactions send or recieved by an IP
> address.
>
> Today you can just watch for incoming/outgoing transactions to determine
> what tx are created in the Node, when you find one you can see the Bitcoin
> address inputs and outputs and track that person's bitcoins.
>
> As an example, SSH provides this kind of encryption, althogh Bitcoin Core
> should ignore fingerprint changes (caused due to reinstalls).
>
> Please feel free to disqus why this is not needed or why you like this
> idea.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo at geneticmistakes.com
> www: http://GeneticMistakes.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/65d3df95/attachment.html>

2023-06-07 15:23:01

- reply

📅 Original date posted:2014-06-17
📝 Original message:But miners dont want to run full nodes, its better to develop some SPV like
that connects to some nodes.
Also I believe that stratum mining protocol improves some performance
things that GBT lacks.
If a new protocol that requires blocks created by miners is developed and
named in a cool way, miners could ask for protocol support to his favourite
pool.
El 17/06/2014 20:26, "Karel Bílek" <kb at karelbilek.com> escribió:
> On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
> <christophe.biocca at gmail.com> wrote:
> > https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> > of the pooling-centralization problems.
>
> This. There is no need to create anything new when GBT already exists.
> In my opinion.
>
> > Unfortunately, it is opt-in,
> > and GHash.io doesn't support it.
>
> Yep. As pools in general are not a part of the bitcoin protocol itself
> (nobody cares how the work happened), I am not sure how this can be
> forced.
>
> > Also most miners don't care and don't do the work to set it up. To do
> > transaction inclusion themselves, they'd need to run a full node,
> > which is a bit more work and resources than just pointing hashpower at
> > a stratum server.
>
> Also, yep. If the miners cared about 51% attack, they wouldn't join
> ghash in the first place. All the miners willingly accept the risk in
> joining the big pool.
>
> K. B.
>
> > If you figure out a way to make GBT widely used (>50% hashpower), kudos
> to you.
> >
> > On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez <rme at i-rme.es> wrote:
> >> First of all I apologice due to the possible mistakes in my writing
> below, I
> >> am not a Bitcoin developer but I have some knowledge about it.
> >>
> >> ----
> >>
> >> We all know the recent news, Ghash pool controlling 51% of the hashrate.
> >> While some consider it a threat others think that is not harmful.
> >>
> >> The thing is that we have to do something to stop this from happening
> again.
> >>
> >> My proposal is to start thinking about miners that join a pool like
> >> independent miners and not slave miners, this includes creating a new
> mining
> >> protocol that does not rely on the pool sending the list of
> transactions to
> >> include in a block. Each individual miner has to collect transactions
> by his
> >> own and mine that, this can be achieved by running a full node or by
> running
> >> a SPV like node that ask other nodes for transactions.
> >>
> >> Once this protocol is developed and standarised we as a community could
> >> require all pools to use it (because its better, because is more
> >> trustless...), not by imposing it but by recommending it.
> >>
> >> Pool owners could send some instructions using this protocol to the
> miner
> >> about how many transactions to include per block (some pools want small
> >> blocks), how many 0 fee transactions to include, how much is the
> minimum fee
> >> per Kb to include transactions and some info about the Coinbase field
> in the
> >> block.
> >>
> >> This way is impossible to perform some of the possible 51% attacks:
> >>
> >> A pool owner cant mine a new chain (selfish mining) (pool clients have
> a SPV
> >> or full node that has checkpoints and ask other peers about the length
> of
> >> the chain)
> >> A pool owner can't perform double spends or reverse transactions (pool
> >> clients know all the transactions relayed to the network, they know if
> they
> >> are already included on a block)
> >> A pool owner cant decide which transactions not to include (but they can
> >> configure the minimum fee).
> >> A pool owner cant get all the rewards by avoiding other pools from
> mining
> >> blocks (Because the pool client knows the last block independently that
> is
> >> from his pool or other).
> >>
> >>
> >> The only thing that a 51% pool owner can do is to shut down his pool and
> >> drop the hashrate by 51% because he does not control the miners.
> >>
> >> If the pool owner owns all the hardware in the pool my proposal is not
> >> valid, if the pool clients dont use this protocol my proposal is not
> valid.
> >>
> >>
> >> I want to know if this is possible or its been developed or there is
> already
> >> a working protocol that works like this, also I want to read other
> people's
> >> ways to address this threat, thanks for reading.
> >>
> >>
> ------------------------------------------------------------------------------
> >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
> Solutions
> >> Find What Matters Most in Your Big Data with HPCC Systems
> >> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> >> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> >> http://p.sf.net/sfu/hpccsystems
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> ------------------------------------------------------------------------------
> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> > Find What Matters Most in Your Big Data with HPCC Systems
> > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> > Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> > http://p.sf.net/sfu/hpccsystems
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/679356fb/attachment.html>

2023-06-07 15:23:00

- reply

📅 Original date posted:2014-06-17
📝 Original message:Because he cant change the coinbase once the proof of work is done.
El 17/06/2014 15:58, "Ron Elliott" <ronaldbelliott at gmail.com> escribió:
> In this scenario how do you ensure the miner solving the block cannot
> reapportion the subsidy to himself rather than the pool?
> On Jun 17, 2014 2:09 AM, "Raúl Martínez" <rme at i-rme.es> wrote:
>
>> First of all I apologice due to the possible mistakes in my writing
>> below, I am not a Bitcoin developer but I have some knowledge about it.
>>
>> ----
>>
>> We all know the recent news, Ghash pool controlling 51% of the hashrate.
>> While some consider it a threat others think that is not harmful.
>>
>> The thing is that we have to do something to stop this from happening
>> again.
>>
>> My proposal is to start thinking about miners that join a pool like
>> independent miners and not slave miners, this includes creating a new
>> mining protocol that does not rely on the pool sending the list of
>> transactions to include in a block. Each individual miner has to collect
>> transactions by his own and mine that, this can be achieved by running a
>> full node or by running a SPV like node that ask other nodes for
>> transactions.
>>
>> Once this protocol is developed and standarised we as a community could
>> require all pools to use it (because its better, because is more
>> trustless...), not by imposing it but by recommending it.
>>
>> Pool owners could send some instructions using this protocol to the miner
>> about how many transactions to include per block (some pools want small
>> blocks), how many 0 fee transactions to include, how much is the minimum
>> fee per Kb to include transactions and some info about the Coinbase field
>> in the block.
>>
>> This way is impossible to perform some of the possible 51% attacks:
>>
>> - A pool owner cant mine a new chain (selfish mining) (pool clients
>> have a SPV or full node that has checkpoints and ask other peers about the
>> length of the chain)
>> - A pool owner can't perform double spends or reverse transactions
>> (pool clients know all the transactions relayed to the network, they know
>> if they are already included on a block)
>> - A pool owner cant decide which transactions not to include (but
>> they can configure the minimum fee).
>> - A pool owner cant get all the rewards by avoiding other pools from
>> mining blocks (Because the pool client knows the last block independently
>> that is from his pool or other).
>>
>>
>> The only thing that a 51% pool owner can do is to shut down his pool and
>> drop the hashrate by 51% because he does not control the miners.
>>
>> If the pool owner owns all the hardware in the pool my proposal is not
>> valid, if the pool clients dont use this protocol my proposal is not valid.
>>
>>
>> I want to know if this is possible or its been developed or there is
>> already a working protocol that works like this, also I want to read other
>> people's ways to address this threat, thanks for reading.
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/d5e763e6/attachment.html>

2023-06-07 15:22:59

- reply

📅 Original date posted:2014-06-17
📝 Original message:First of all I apologice due to the possible mistakes in my writing below,
I am not a Bitcoin developer but I have some knowledge about it.
----
We all know the recent news, Ghash pool controlling 51% of the hashrate.
While some consider it a threat others think that is not harmful.
The thing is that we have to do something to stop this from happening again.
My proposal is to start thinking about miners that join a pool like
independent miners and not slave miners, this includes creating a new
mining protocol that does not rely on the pool sending the list of
transactions to include in a block. Each individual miner has to collect
transactions by his own and mine that, this can be achieved by running a
full node or by running a SPV like node that ask other nodes for
transactions.
Once this protocol is developed and standarised we as a community could
require all pools to use it (because its better, because is more
trustless...), not by imposing it but by recommending it.
Pool owners could send some instructions using this protocol to the miner
about how many transactions to include per block (some pools want small
blocks), how many 0 fee transactions to include, how much is the minimum
fee per Kb to include transactions and some info about the Coinbase field
in the block.
This way is impossible to perform some of the possible 51% attacks:
- A pool owner cant mine a new chain (selfish mining) (pool clients have
a SPV or full node that has checkpoints and ask other peers about the
length of the chain)
- A pool owner can't perform double spends or reverse transactions (pool
clients know all the transactions relayed to the network, they know if they
are already included on a block)
- A pool owner cant decide which transactions not to include (but they
can configure the minimum fee).
- A pool owner cant get all the rewards by avoiding other pools from
mining blocks (Because the pool client knows the last block independently
that is from his pool or other).
The only thing that a 51% pool owner can do is to shut down his pool and
drop the hashrate by 51% because he does not control the miners.
If the pool owner owns all the hardware in the pool my proposal is not
valid, if the pool clients dont use this protocol my proposal is not valid.
I want to know if this is possible or its been developed or there is
already a working protocol that works like this, also I want to read other
people's ways to address this threat, thanks for reading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/9529a793/attachment.html>

2023-06-07 15:22:32

- reply

📅 Original date posted:2014-06-10
📝 Original message:I believe that the Payment Protocol works that way, the merchant broadcast
the Tx.
El 10/06/2014 13:23, "Chris D'Costa" <chrisjdcosta at gmail.com> escribió:
> I wonder if Raul is mistakenly under the impression that the transaction
> only reaches the Bitcoin network via Alice? In which case the premise of
> this "attack" is incorrect.
>
> *Chris D'Costa*
>
>
> Follow on Twitter: *@cjdcosta*
>
> *---------------------------------------------------------------------------------------*
> chris.dcosta at meek.io (Meek)
> chris.dcosta at sossee.com (Blog)
> chrisjdcosta at gmail.com <chris_dcosta at me.com> (Personal)
> chris.dcosta at bitcoinassociation.be (Belgian Bitcoin Association)
>
> ---------------------------------------------------------------------------------------
>
>
> On 7 June 2014 00:02, Raúl Martínez <rme at i-rme.es> wrote:
>
>> I dont know if this attack is even possible, it came to my mind and I
>> will try to explain it as good as possible.
>>
>> Some transacions keep unconfirmed forever and finally they are purged by
>> Bitcoin nodes, mostly due to the lack of fees.
>>
>>
>> Example:
>> ---------
>>
>> Alice is selling a pizza to Bob, Bob is now making the payment with
>> Bitcoin.
>> The main goal of this attack is to store a unconfirmed transaction send
>> by Bob for a few days (it will not be included in the blockchain because it
>> has no fee or due to other reason), Bob might resend the payment or might
>> just cancel the deal with Alice.
>>
>> Bob forgets about that failed trade but a couple of days later, Alice,
>> who has stored the signed transacion, relays the transaction to the network
>> (or mines it directly with his own hashpower).
>> Bob does not know what is happening, he believed that that transaction
>> was "canceled forever", he even does not remember the failed pizza deal.
>>
>> Alice has now the bitcoins and Bob does not know what happened with his
>> money.
>>
>> ---------
>>
>> This might also work with the Payment Protocol because when using it Bob
>> does not relay the transaction to the network, its Alices job to do it,
>> Alice stores it and tells Bob to resend the payment, Bob creates another
>> transaction (If has the same inputs as the first TX this does not work)
>> (this one is relayed by Alice to the network).
>>
>> Alice comes back a couple of days later and mines with his hashrate the
>> first transaction (the one she didnt relayed to the network).
>>
>> Alice now has two payments, Bob does not know what happened.
>>
>>
>> -----------
>>
>> I hope that I explained well this possible attack, I dont know if there
>> is already a fix for this problem or if it is simply impossible to execute
>> this kind of attack.
>>
>> Thanks for your time.
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140610/d7a8ec9c/attachment.html>

2023-06-07 15:22:32

- reply

📅 Original date posted:2014-06-06
📝 Original message:I dont know if this attack is even possible, it came to my mind and I will
try to explain it as good as possible.
Some transacions keep unconfirmed forever and finally they are purged by
Bitcoin nodes, mostly due to the lack of fees.
Example:
---------
Alice is selling a pizza to Bob, Bob is now making the payment with Bitcoin.
The main goal of this attack is to store a unconfirmed transaction send by
Bob for a few days (it will not be included in the blockchain because it
has no fee or due to other reason), Bob might resend the payment or might
just cancel the deal with Alice.
Bob forgets about that failed trade but a couple of days later, Alice, who
has stored the signed transacion, relays the transaction to the network (or
mines it directly with his own hashpower).
Bob does not know what is happening, he believed that that transaction was
"canceled forever", he even does not remember the failed pizza deal.
Alice has now the bitcoins and Bob does not know what happened with his
money.
---------
This might also work with the Payment Protocol because when using it Bob
does not relay the transaction to the network, its Alices job to do it,
Alice stores it and tells Bob to resend the payment, Bob creates another
transaction (If has the same inputs as the first TX this does not work)
(this one is relayed by Alice to the network).
Alice comes back a couple of days later and mines with his hashrate the
first transaction (the one she didnt relayed to the network).
Alice now has two payments, Bob does not know what happened.
-----------
I hope that I explained well this possible attack, I dont know if there is
already a fix for this problem or if it is simply impossible to execute
this kind of attack.
Thanks for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140607/c2a4569b/attachment.html>

2023-06-07 15:22:31

- reply

📅 Original date posted:2014-06-06
📝 Original message:Alice does not intercept the transaction, she only saves it and expect that
it will not be confirmed (because has 0 fee for example).
Also using the Payment Protocol I believe that Alice is the only person
that can relay Bob's transaction.
Source: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
*When the merchant's server receives the Payment message, it must determine
> whether or not the transactions satisfy conditions of payment. If and only
> if they do, if should broadcast the transaction(s) on the Bitcoin p2p
> network.*
>
2014-06-07 0:11 GMT+02:00 Toshi Morita <toshi at peernova.com>:
> From what I know, Alice does not know to which node Bob will broadcast the
> transaction. Therefore, Alice cannot intercept the transaction and prevent
> the rest of the network from seeing it.
>
> Toshi
>
>
>
> On Fri, Jun 6, 2014 at 3:02 PM, Raúl Martínez <rme at i-rme.es> wrote:
>
>> I dont know if this attack is even possible, it came to my mind and I
>> will try to explain it as good as possible.
>>
>> Some transacions keep unconfirmed forever and finally they are purged by
>> Bitcoin nodes, mostly due to the lack of fees.
>>
>>
>> Example:
>> ---------
>>
>> Alice is selling a pizza to Bob, Bob is now making the payment with
>> Bitcoin.
>> The main goal of this attack is to store a unconfirmed transaction send
>> by Bob for a few days (it will not be included in the blockchain because it
>> has no fee or due to other reason), Bob might resend the payment or might
>> just cancel the deal with Alice.
>>
>> Bob forgets about that failed trade but a couple of days later, Alice,
>> who has stored the signed transacion, relays the transaction to the network
>> (or mines it directly with his own hashpower).
>> Bob does not know what is happening, he believed that that transaction
>> was "canceled forever", he even does not remember the failed pizza deal.
>>
>> Alice has now the bitcoins and Bob does not know what happened with his
>> money.
>>
>> ---------
>>
>> This might also work with the Payment Protocol because when using it Bob
>> does not relay the transaction to the network, its Alices job to do it,
>> Alice stores it and tells Bob to resend the payment, Bob creates another
>> transaction (If has the same inputs as the first TX this does not work)
>> (this one is relayed by Alice to the network).
>>
>> Alice comes back a couple of days later and mines with his hashrate the
>> first transaction (the one she didnt relayed to the network).
>>
>> Alice now has two payments, Bob does not know what happened.
>>
>>
>> -----------
>>
>> I hope that I explained well this possible attack, I dont know if there
>> is already a fix for this problem or if it is simply impossible to execute
>> this kind of attack.
>>
>> Thanks for your time.
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140607/6bd6e287/attachment.html>

2023-06-07 15:22:30

- reply

2023-06-07 15:21:42

- reply

📅 Original date posted:2014-05-18
📝 Original message:About the small number of bitcoin nodes:
Hi, I read the message that Mike Hearn sent to this mailing list some days
ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes.
As an owner of two Bitcoin Nodes, one in my home computer and one in a
dedicated server, I believe I can contribute with some of my thoughts and
ideas:
- Allow users to view the bandwith used by Bitcoin Core:
This is available in the Bitcoin Core GUI (btw, when the computer is
restarted the data gets reseted) but I cant find it in the bitcoind
commandline, people that run nodes want to see the amount of GB that they
have "donated" to the network.
- Educate users about the correct setup of a bitcoin node:
Add a page in the bitcoin.org website with a tutorial about running Bitcoin
Core with the ports opened, about runing bitcoind, etc. This guide shoud
not be for regular users but for advanced ones.
- bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
start:
The first time the software should create a default config file with a
random RCP password and username (user can change it later) and the config
file should be commented so the user can know how to change configurations.
This is very useful in setups without GUI, for example in Ubuntu Server.
- bitcoind and Bitcoin Core should be in Linux repos:
People want to type "yum install bitcoind" or "apt-get install bitcoind"
and install bitcoin. No one wants to follow a tutorial made by somewho
saying that you have to add external repos to install bitcoin in your
server.
For example Electrum has been added to Ubuntu software center recently.
Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu
Server repos.
- Create a "grafical interface" for bitcoind on Linux servers:
Create a command, for example "bitcoind show" that shows a nice summary in
your Terminal (Console) with all the data that a node administrator wants
to know.
When I say "grafical interface" I mean like "top" command, an interface
made out of characters in ASCII.
- Split Bitcoin Wallet from Bitcoin Node:
I believe that this is planned, some people want to help the network and
others want to keep a wallet, someones want both.
With bitcoind you can use the option "disablewallet=1" that allows to save
some memory.
- Inform users if 8333 port is closed:
That should be more visible, I dont mean an alert or warning but some icon.
- Keep connections if bitcoind is restarted:
I noticed that if I restart bitcoind (to apply new config) my reset to 0
and take some hours to rise up to ~40. I believe that my peers should
notice that I am down for less than ~15 minutes and try to connect again
faster.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/d0f1a16a/attachment.html>

2023-06-07 15:21:42

- reply

📅 Original date posted:2014-05-18
📝 Original message:About the small number of bitcoin nodes:
Hi, I read the message that Mike Hearn sent to this mailing list some days
ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes.
As an owner of two Bitcoin Nodes, one in my home computer and one in a
dedicated server, I believe I can contribute with some of my thoughts and
ideas:
- Allow users to view the bandwith used by Bitcoin Core:
This is available in the Bitcoin Core GUI (btw, when the computer is
restarted the data gets reseted) but I cant find it in the bitcoind
commandline, people that run nodes want to see the amount of GB that they
have "donated" to the network.
- Educate users about the correct setup of a bitcoin node:
Add a page in the bitcoin.org website with a tutorial about running Bitcoin
Core with the ports opened, about runing bitcoind, etc. This guide shoud
not be for regular users but for advanced ones.
- bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
start:
The first time the software should create a default config file with a
random RCP password and username (user can change it later) and the config
file should be commented so the user can know how to change configurations.
This is very useful in setups without GUI, for example in Ubuntu Server.
- bitcoind and Bitcoin Core should be in Linux repos:
People want to type "yum install bitcoind" or "apt-get install bitcoind"
and install bitcoin. No one wants to follow a tutorial made by somewho
saying that you have to add external repos to install bitcoin in your
server.
For example Electrum has been added to Ubuntu software center recently.
Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu
Server repos.
- Create a "grafical interface" for bitcoind on Linux servers:
Create a command, for example "bitcoind show" that shows a nice summary in
your Terminal (Console) with all the data that a node administrator wants
to know.
When I say "grafical interface" I mean like "top" command, an interface
made out of characters in ASCII.
- Split Bitcoin Wallet from Bitcoin Node:
I believe that this is planned, some people want to help the network and
others want to keep a wallet, someones want both.
With bitcoind you can use the option "disablewallet=1" that allows to save
some memory.
- Inform users if 8333 port is closed:
That should be more visible, I dont mean an alert or warning but some icon.
- Keep connections if bitcoind is restarted:
I noticed that if I restart bitcoind (to apply new config) my reset to 0
and take some hours to rise up to ~40. I believe that my peers should
notice that I am down for less than ~15 minutes and try to connect again
faster.
Thanks for reading
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/a18d3d02/attachment.html>