Nearly all of these new(er) user-mode transports run over UDP, so you can
hole-punch and port forward just the same. Some which don't can
nevertheless be tunneled, to the same effect.
Ultimately I don't have any skin in this game though. Just trying to save
someone from reinventing a perfectly goo
On Sat, Mar 23, 2013 at 9:22 PM, Gregory Maxwell wrote:
> In some ways SCTP is a pretty optimal transport for Bitcoin like messaging.
Darn near everything can be shoehorned into a "message" So
absolutely agreed... in theory. Been an SCTP fan for years.
Firewall practices tend to put a damper
On Sat, Mar 23, 2013 at 5:57 PM, Jay F wrote:
> My first concern was that I and about everyone else only has TCP/UDP
> port forwarding,
You tunnel it!
http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-dtls-encaps-00
You could do worse to have a data stream that looks like WEBRTC traffic…
In so
My first concern was that I and about everyone else only has TCP/UDP
port forwarding, but at least for the first:
UDT uses UDP to transfer bulk data with its own reliability control and
congestion control mechanisms. Multiple UDT flows can share a single UDP
port, thus a firewall can open only
If you're considering a datagram protocol, you might be interested in some
more modern alternatives to UDP:
UDT: Breaking the Data Transfer Bottleneck
http://udt.sourceforge.net/
Stream Control Transmission Protocol
http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
On Sat, Mar
On 03/23/2013 11:24 AM, Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr wrote:
>> On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
>>> Introducing super-nodes with thousands of connected peers can greatly help
>>> here.
>>
>> UDP is connectionless.
>> I would hope any U
On Sat, Mar 23, 2013 at 10:47 AM, Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr wrote:
>> Not for producing coinbases (where BIP 34 is implemented).
> Sure, that is largely the pool server layer. But it is misleading to
> imply that bitcoind is nowhere in the stack.
You're both
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr wrote:
> > bitcoind is nowhere in the implementation of the miner end of BIP 34.
>
> Again, not strictly true.
>
> bitcoind's 'getblocktemplate' RPC call used by some supplies the block
> version
On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr wrote:
> bitcoind is nowhere in the implementation of the miner end of BIP 34.
Again, not strictly true.
bitcoind's 'getblocktemplate' RPC call used by some supplies the block
version, selects transactions for the miner, and other tasks integral
to the im
On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr wrote:
> I don't think anyone is mining using bitcoind 0.7 or later?
slush, BTC Guild, ozcoin too I think, several others.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
--
Ev
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr wrote:
> > On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
> >> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr wrote:
> >> > I don't think anyone is mining using bitcoind 0.7 or later?
> >>
>
On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr wrote:
> On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
>> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr wrote:
>> > I don't think anyone is mining using bitcoind 0.7 or later?
>>
>> slush, BTC Guild, ozcoin too I think, several others.
>
> Not for p
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr wrote:
> > I don't think anyone is mining using bitcoind 0.7 or later?
>
> slush, BTC Guild, ozcoin too I think, several others.
Not for producing coinbases (where BIP 34 is implemented).
--
On Saturday, March 23, 2013 4:16:19 PM Jeff Garzik wrote:
> Users should not be impacted. Some ancient miners will produce
> newly-invalid blocks (v1), that will get ignored. The easy solution
> is to mine using a recent bitcoind (0.7 or later). If you are a miner
> and need help upgrading to v2
Once a supermajority (95%) of mining reaches block version 2,
nVersion==1 blocks will be rejected. This event seems likely to occur
in the next week.
Version 2 block specification: https://en.bitcoin.it/wiki/BIP_0034
Watching for the event: http://blockorigin.pfoe.be/top.php The text
is at the
On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr wrote:
> On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
>> Introducing super-nodes with thousands of connected peers can greatly help
>> here.
>
> UDP is connectionless.
> I would hope any UDP bitcoin protocol doesn't try to emulate a connecti
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
> Introducing super-nodes with thousands of connected peers can greatly help
> here.
UDP is connectionless.
I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/
Luke
-
Not looked at code yet, some thoughts:
1) In IPv4 max UDP data size is 65507 bytes.
2) What about big messages (block)?
3) I think relay speed can be increased only by reducing network diameter.
Introducing super-nodes with thousands of connected peers can greatly help here.
4) The only (IMO) UD
Here is a rough draft implementation of a UDP P2P protocol extension
for bitcoin:
https://github.com/jgarzik/bitcoin/tree/udp
http://yyz.us/bitcoin/udp-v0.patch
Protocol specification (such that it is):
- UDP, bound to same port as TCP P2P (normally 8333)
- Active, simultaneous TCP P2P
19 matches
Mail list logo
